DEV Community: Henrique Cavarsan

kftui - A better way to manage kubectl port-forwards

Henrique Cavarsan — Mon, 25 Aug 2025 13:39:14 +0000

First of all - kftray and kftui are independent, cross-platform applications. They help you set up and manage multiple port-forwarding settings easily. Both apps are basically the same tool with different interfaces. kftray is the GUI version with windows and buttons. kftui is the terminal version that runs in your command line. They share the same database and configs. Set up a port-forward in kftray's GUI, and you'll see it in kftui too. Save something in kftui, and it shows up in kftray. You can use whichever one you prefer or switch between them.

So... the kftray/kftui docs are pretty messy right now, and I figured writing this blog post would be easier than fixing everything properly. I'll organize the docs later, but this should cover what kftui does and how to use it.

kftui has most of the same stuff as kftray, but this guide is just about the terminal version.

Why Build a Terminal Interface?

I built kftui to address some practical limitations of GUI applications. Terminal interfaces use significantly fewer system resources, which matters in resource-constrained environments. They work well over SSH connections without requiring X11 forwarding or remote desktop setups.

From a development perspective, maintaining one codebase in Rust is simpler than managing separate frontend and backend projects. This approach reduces complexity and keeps the tool focused on core functionality.

If you've worked with multiple kubectl port-forward processes in different terminal windows, you know how quickly it becomes difficult to manage. kftui provides a centralized way to handle these connections.

Installation

You'll need curl or wget installed. Windows users need PowerShell.

Unix-like systems (Linux, macOS, WSL):

Using cargo:

cargo install kftui

Using Homebrew:

brew tap hcavarsan/kftray
brew install kftui

Using curl:

bash <(curl -s https://raw.githubusercontent.com/hcavarsan/kftray/main/hacks/kftui_installer.sh)

Using wget:

bash <(wget -qO- https://raw.githubusercontent.com/hcavarsan/kftray/main/hacks/kftui_installer.sh)

Windows:

Invoke-Expression ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/hcavarsan/kftray/main/hacks/kftui_installer.ps1'))

After installation, restart your terminal and verify it works:

kftui

Basic Usage

Start with a simple configuration file. Create config.json:

[
  {
    "alias": "my-api",
    "context": "minikube",
    "namespace": "default",
    "service": "api-service",
    "local_port": 8080,
    "remote_port": 80,
    "protocol": "tcp",
    "workload_type": "service"
  }
]

Launch kftui with this configuration:

kftui --configs-path config.json

The interface displays your configuration in the "Stopped" table on the left. Press f to start the port-forward. The configuration moves to the "Running" table on the right, and your service becomes accessible at localhost:8080. Press f again to stop it.

Persistent Storage

To avoid specifying the config file path repeatedly, save configurations to kftui's database:

kftui --configs-path config.json --save

After saving, run kftui without arguments to access your stored configurations. This approach works well for frequently used port-forward setups.

Configuration Sources

kftui supports several ways to load configurations, each suited to different workflows.

Local Files

Load configurations from local JSON files:

kftui --configs-path /path/to/config.json

GitHub Repositories

Import configurations from version-controlled repositories:

kftui --github-url https://github.com/your-team/k8s-configs --configs-path environments/dev.json

This method works well for teams that maintain environment-specific configurations in version control.

Inline JSON

Pass JSON configuration directly for scripting scenarios:

kftui --json '[{"alias":"test","namespace":"default","service":"my-service","local_port":8080,"remote_port":80,"protocol":"tcp","workload_type":"service"}]'

Standard Input

Read configurations from stdin for pipeline integration:

echo '[{"alias":"api",...}]' | kftui --stdin

Command-Line Options

--save: Store configurations in the database for future use
--flush: Clear existing configurations before importing new ones
--auto-start: Start all port-forwards immediately after loading
--non-interactive: Run without the interface for automation scripts

Service Auto-Discovery

Rather than manually creating configuration files, kftui can discover services through Kubernetes annotations. This approach keeps port-forward configurations synchronized with service definitions.

Add annotations to your Kubernetes services:

apiVersion: v1
kind: Service
metadata:
  name: monitoring-stack
  namespace: observability
  annotations:
    kftray.app/configs: "grafana-3000-3000,prometheus-9090-9090,alertmanager-9093-9093"
spec:
  selector:
    app: monitoring
  ports:
    - name: grafana
      port: 3000
    - name: prometheus
      port: 9090
    - name: alertmanager
      port: 9093

The annotation format is alias-local_port-remote_port. Multiple configurations are separated by commas.

To use auto-discovery, navigate to the top menu in kftui and select "Auto Add". Choose your Kubernetes context from the available options, and kftui will create configurations for all annotated services in that context.

Interface Organization

The interface consists of four main areas:

Top menu bar: Contains Help, Auto Add, Import, Export, Settings, About, and Exit options
Stopped configurations (left): Displays configurations ready to start
Running configurations (right): Shows active port-forwards with status information
Details panel (bottom): Provides information about the selected configuration

Menu Navigation

The top menu provides seven functions:

Help: Display usage information and keyboard shortcuts
Auto Add: Discover services from your Kubernetes cluster
Import: Load configuration files through a file browser
Export: Save current configurations to a JSON file
Settings: Configure application behavior
About: Show version and project information
Exit: Stop all active port-forwards and close the application

Navigate menu items with ←/→ arrow keys and press Enter to select.

Application Settings

Access settings by pressing s or selecting Settings from the menu.

Disconnect Timeout: Configure automatic disconnection after a specified period of inactivity. Set to 0 to disable automatic timeouts.
Network Monitor: Enable or disable network connectivity monitoring. When enabled, kftui monitors network status and attempts to reconnect dropped port-forwards.

Settings persist between application sessions.

HTTP Request Logging

kftui provides HTTP request and response logging for debugging network traffic through port-forwards.

Enable logging by setting "http_logs_enabled": true in your configuration file, or toggle it for existing configurations by pressing l in the interface.

HTTP Logs Viewer

Press Shift+V to open the HTTP logs viewer, which operates in two modes:

List Mode (default view):

Displays all HTTP requests with timestamps and status codes
Navigate requests with ↑/↓ arrow keys
Use PageUp/PageDown to scroll through multiple entries
Press Enter on any request to view detailed information
Press a to toggle automatic scrolling for new requests

Detail Mode (activated by pressing Enter on a request):

Shows complete request and response information including headers and body content
Scroll through details with ↑/↓ arrow keys
Use PageUp/PageDown for faster navigation
Press r to replay the selected request
Press Esc to return to list mode

HTTP Logs Configuration

Press L to configure HTTP logging behavior:

Enable or disable logging for individual configurations
Set maximum log file size (1-1000 MB)
Configure retention period (1-365 days)
Enable automatic cleanup of old log files

Complete Keyboard Reference

Key	Function
`f`	Start or stop port-forward
`i`	Import configurations
`e`	Export configurations
`d`	Delete selected configurations
`a`	Select all configurations
`Space`	Toggle individual selection
`Tab`	Switch between interface components
`←/→`	Navigate menu items
`s`	Open settings
`h`	Show help information
`q`	Show about information
`l`	Toggle HTTP logging
`L`	Configure HTTP logging
`V`	View HTTP logs
`o`	Open HTTP logs in external editor
`↑/↓`	Navigate within sections
`PageUp/PageDown`	Scroll through content
`Home/End`	Jump to first/last item
`Ctrl+C`	Exit application

Configuration File Structure

Configuration files use JSON format with the following fields:

{
  "alias": "my-service",           // Display name in interface
  "namespace": "production",       // Kubernetes namespace (required)
  "service": "api-service",        // Target service name
  "local_port": 8080,             // Local binding port
  "remote_port": 80,              // Remote service port
  "protocol": "tcp",              // Network protocol (required)
  "workload_type": "service",     // Target type: "service" or "pod"
  "context": "prod-cluster",      // Kubernetes context
  "kubeconfig": "/path/to/config", // Kubeconfig file path
  "http_logs_enabled": true       // Enable HTTP logging
}

The minimum required fields are namespace and protocol. When ports are not specified, kftui attempts to determine appropriate values from the service definition.

How kftui Relates to kftray

What kftui Can Do

kftui handles pretty much everything the kftray GUI does, just through terminal commands and keyboard shortcuts. The auto-discovery stuff saves time by reading your Kubernetes service annotations instead of making you type configs manually. The HTTP logging is useful for debugging API calls and seeing what requests are going through your port-forwards.

If you work mostly in terminals or need to manage port-forwards over SSH, kftui covers everything without needing a desktop environment.

Demo Video

In this quick demo video, I've tested both tools with the same setup - port forwarding to a service while running curl in a loop. Then deleted all pods with kubectl delete pods --all --force to see how each handles recovery.

kubectl port forward: When pods get deleted, the port forward just dies even though it's forwarding to a service. All requests fail and you have to manually restart it.
kftray: Loses maybe one request when pods get deleted. The watcher detects changes immediately and reconnects to new pods as they come up. The curl loop keeps going like nothing happened.

Demo Video HTTP Logs:

Video demonstration on how to inspect HTTP traffic throug requests in port forwarding.

Additional Resources

For more information:

If you find kftray or kftui useful, consider starring the project on GitHub ⭐

Design contract infra

Henrique Cavarsan — Sat, 24 May 2025 23:22:33 +0000

Debugging Kubernetes Services with KFtray's HTTP Logs and VS Code REST Client Extension

Henrique Cavarsan — Wed, 05 Mar 2025 21:13:22 +0000

If you've worked with Kubernetes, you already know the debugging headaches it can cause. But what makes it particularly difficult?

First, there's the distributed architecture. Your applications run across multiple nodes and namespaces, with traffic flowing through various system layers.

Second, environments constantly change. Pods start, stop, and reschedule themselves. Configuration changes happen frequently.

And production environments? They add a whole new level of complexity. Issues often manifest differently in production due to scale, load, or configuration variations. Security policies typically restrict direct access to services.

Have you ever found a bug in development that behaves completely differently in production? You're not alone.

Common Debugging Options for Kubernetes

Most developers rely on a few standard approaches when debugging Kubernetes services. Each has its strengths—and limitations.

Manual Request Tools

Tools like Postman, Insomnia, and curl let you test endpoints directly. They're useful for simple tests, but they come with constraints:

Each request must be manually created
They can't capture live traffic patterns
You often need multiple tools during a debugging session

These tools work well in controlled situations but may fall short when dealing with complex, real-world traffic patterns.

Proxy-Based Solutions

Proxy tools like Charles Proxy and mitmproxy provide deeper traffic visibility. But there's more to it:

Certificate management can be complex
Workflow integration isn't always smooth
They sometimes capture too much traffic

While useful, these tools often feel disconnected from your development environment, requiring constant context switching.

Network Analysis Tools

Low-level tools like Wireshark offer comprehensive traffic inspection but generally provide more information than needed:

They have a steep learning curve
The level of detail can be overwhelming
They lack application context

These tools are great at network-level debugging but can make application-level analysis more complex than necessary.

An Alternative Approach with KFtray HTTP Logging

I've found that KFtray offers an approach to Kubernetes debugging by adding HTTP traffic logging capabilities to standard port-forwarding.

It functions as a proxy layer that:

Records HTTP traffic through port-forwards
Maintains standard port-forward functionality
Integrates with existing development workflows

This approach provides additional visibility into service interactions while using familiar port-forwarding mechanics.

You might be asking yourself: "How does this actually work with VS Code?" That's what i'll explore next.

How KFtray's HTTP Logging Works

When you enable HTTP logging for a port-forward configuration in KFtray, a series of events unfolds:

Start a port forward with http logging option enabled
The app itself captures incoming HTTP requests
Requests are forwarded to your Kubernetes service
Responses are captured on their return journey
Complete request-response pairs are logged with correlation IDs

This process enables traffic capture without requiring application changes or additional debugging tools.

And these logs are formatted in a way that works seamlessly with VS Code.

Setting Up HTTP Logging in KFtray

Setting up HTTP logging in KFtray is an simple process that begins with downloading and installing KFtray v0.16.1 or later from the GitHub releases page. Once you have KFtray installed, you'll need to configure your port-forward settings.

Start by launching KFtray and creating a new port-forward configuration. You'll need to specify your Kubernetes environment details, including your desired context and the namespace where your service runs. Make sure to enter the correct service name – this is the Kubernetes service you want to monitor.

Next, configure your port settings. The local port is where you'll access the service on your machine, while the remote port is where the service runs in your Kubernetes cluster. Give your configuration a descriptive name that helps you identify it easily later. This name will be particularly helpful when you're managing multiple port-forwards.

With your configuration in place, enable the port-forward by toggling the switch in the KFtray interface. Then, click the menu icon next to your port-forward configuration and enable HTTP logging. This simple step activates the logging feature for your selected port-forward.

KFtray will now automatically capture all HTTP traffic flowing through your port-forward. The logs are saved to $HOME/.kftray/http_logs/, and each log file is named using your configuration ID and local port for easy reference.

Now that you have logging set up, let's explore what makes these logs particularly valuable for debugging and development.

Understanding the HTTP Log Format

The HTTP logs generated by KFtray are structured in a specific format that's compatible with VS Code's REST Client extension. Each entry contains complete details about the HTTP interaction:

curl 'http://127.0.0.1:8787/gzip' --compressed -H 'User-Agent: Test'

# ----------------------------------------
# Trace ID: 651bc5a5-fb13-46ec-b471-473f08a1f828
# Request at: 2025-03-05T16:56:00.076606+00:00
GET /gzip HTTP/1.1
Host: 127.0.0.1:8787
Accept: */*
Accept-Encoding: deflate, gzip
User-Agent: Test

#<empty body>

###

# ----------------------------------------
# Trace ID: 651bc5a5-fb13-46ec-b471-473f08a1f828
# Response at: 2025-03-05T16:56:00.079206+00:00
# Took: 2 ms
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Content-Encoding: gzip
Content-Length: 150
Content-Type: application/json; encoding=utf-8
Date: Wed, 05 Mar 2025 16:56:00 GMT


{
  "headers": {
    "Accept": [
      "*/*"
    ],
    "Accept-Encoding": [
      "deflate, gzip"
    ],
    "Host": [
      "127.0.0.1:8787"
    ],
    "User-Agent": [
      "Test"
    ]
  },
  "origin": "127.0.0.1:56846",
  "gzipped": true
}

The log format includes several key components:

Trace ID: Each request-response pair shares a unique identifier
Timestamps and Duration: Useful for identifying performance issues
Complete HTTP Details: Includes headers, status codes, and body content

This format is what makes the logs directly usable with VS Code's REST Client.

Integrating with VS Code REST Client

The REST Client extension for VS Code is a powerful tool for testing HTTP requests. When combined with KFtray's logs, it creates a workflow for debugging Kubernetes services.

To use this integration:

Install the REST Client extension from the VS Code marketplace
Open a KFtray-generated log file in VS Code
The extension automatically recognizes HTTP requests in the file
Use the "Send Request" button to replay any captured request

Note: You can modify parameters, headers, or body content before replaying a request,
making it easy to test different scenarios.

Note: This approach works alongside existing debugging tools rather than replacing them.
It can complement your current development workflow.

This integration allows you to conduct debugging within your code editor, potentially reducing the need to switch between multiple tools.

How can it help?

Here are some common scenarios in which these tools can be useful.

Diagnosing Intermittent API Errors

Production services sometimes experience sporadic errors that are difficult to reproduce. This approach can help:

Enable HTTP logging for the service's port-forward
Monitor the application until the error occurs
Review the HTTP logs for failing requests:

# ----------------------------------------
# Trace ID: 5525d312-5582-46ad-85d1-0fd3710f824e
# Response at: 2025-03-01T15:34:09.901304+00:00
# Took: 144 ms
HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{
  "error": "Failed to connect to database",
  "code": "DB_CONNECTION_ERROR"
}

Use VS Code REST Client to replay the exact request to verify the error pattern

This method can help make intermittent failures more reproducible and easier to debug.

Tracking Microservice Communication

Microservice architectures create complex communication patterns that can be difficult to visualize. HTTP logging helps by capturing traffic across multiple service port-forwards, recording complete request and response cycles, maintaining trace ID correlation across services, and providing timing data for each interaction. This visibility can help identify communication patterns and potential areas for optimization.

Troubleshooting Authentication Flows

Authentication systems typically involve multiple steps of token exchange and validation. With HTTP logging, you can:

Record complete authentication request sequences
Preserve header information and token data
Replay requests with modified parameters
Maintain the full context of authentication flows

All that being said, the real value comes from how these tools fit into your existing development workflow.

Conclusion

Combining KFtray's HTTP logging with VS Code's REST Client extension offers an additional option for debugging Kubernetes services. This approach provides a way to capture and replay HTTP traffic that can simplify some debugging scenarios.

The format compatibility between KFtray's logs and VS Code REST Client creates a workflow that includes:

Capturing service interactions with context
Documenting intermittent issues
Providing request replay capabilities
Supplementing existing debugging approaches

i believe this combination of tools could be helpful in certain Kubernetes debugging scenarios. i'm curious to see how you might apply this approach to your own debugging challenges.

If you're interested in exploring this further, you can find more information on the KFtray GitHub repository.

Feedback and contributions are welcome.

A bit about OSS Licenses using LEGO analogy

Henrique Cavarsan — Fri, 01 Nov 2024 13:04:48 +0000

Link to original article: https://kftray.app/blog/posts/9-oss-legos

Note: This article was heavily inspired by a video called What is Open Source explained in LEGO from 10 years ago which is very well explained. The video used LEGO to explain open source in a simple way. I wanted to build on that idea by using LEGO to explain the different types of open source licenses.

So, imagine you have a giant box of Lego bricks. You love creating all sorts of things—spaceships, castles, robots—and you often invite your friends over to build together.
Sometimes, you come up with an amazing creation and want others to enjoy it too. But you also want to make sure everyone plays fair and knows how they can use your designs. That's where open source licenses come into play.

Permissive vs Copyleft Licenses

Just like you might have different rules for sharing your Lego creations, open source licenses come in two main types: permissive and copyleft.

Permissive licenses Allow others to use, modify, and distribute your work with minimal restrictions.
Copyleft licenses Ensures that all future versions remain free and open.

Permissive Licenses - The "Do What You Want" and "No Warranty" Rule

Alex takes your Lego castle and transforms it into a futuristic fortress. He decides to display it at a local event without mentioning you. While you might wish he gave you credit, your "do what you want" rule means he's allowed to do that. Your castle idea has inspired new creations, even if you don't see the direct benefits.

Suppose you tell Alex, Here's my Lego castle. You can do whatever you like with it—even keep it, change it completely, or sell it at the school fair. But if anything goes wrong—like the blocks breaking—it's not my fault. This gives Alex complete freedom over what he does with your creation while also letting him know that you're not responsible for any problems.

This is like a permissive license such as the MIT License. People can use the code in any way they want, even in their own projects that they might sell or keep private. The "no warranty" part is a common clause in these licenses, stating that the software is provided "as is," without any guarantees.

Another example of a permissive license is the BSD 3-Clause License. While it allows free use, modification, and distribution like the MIT License, it requires that credit be given to the original author.

Edit Note: I have misunderstood about BSD license, before I mentioned that BSD does not require attribution, but after this reddit comment, I figured out that I was incorrect about BSD as the BSD license is permissive but requires attribution.

Copyleft Licenses - The "Share Alike" Rule

Alex takes your Lego spaceship, adds a cool warp drive, and improves the laser cannon. Thanks to your "share alike" rule, Alex shares the enhanced spaceship with you, and now you can both enjoy an even better version. This continuous sharing leads to amazing creations neither of you could have built alone.

Imagine you build an awesome Lego spaceship with unique features—a rotating laser cannon and hidden compartments. You tell Alex, You can add more pieces or change it, but if you do, you have to share your new creation with me too, and make sure you keep the same rules I have. This way, any improvements Alex makes are shared with you under the same conditions.

In software, this is similar to a copyleft license like the GNU General Public License (GPL). If someone uses code licensed under the GPL and makes it better, they must also share their improved code with others under the same license. This encourages ongoing sharing and ensures that the software and its enhancements remain available to everyone.

Some people think that using GPL-licensed code means they can't sell their software, but that's not true (GPL FAQ on selling software). You can sell your software, but you must also provide the source code under the same GPL license. This approach fosters a community where everyone benefits from each other's contributions.

Strong Copyleft for Network Software - The Affero GPL

Alex takes your online Lego guide, adds new sections, and hosts it on his website. Because of your rule, he shares his improved guide with you, ensuring that you both benefit from the enhancements.

Imagine you create an online guide to building Lego models and say to Alex, You can use and change my guide, but if you make it better and share it with others, even online, you need to share your changes with me. This ensures that improvements are shared, no matter how they are distributed.

This is like the GNU Affero General Public License (AGPL). It's similar to the GPL but adds that if you use the software over a network (like a web server), you must make the source code available to users interacting with it.

Some think the AGPL restricts the use of software in web applications. While it does require sharing modifications when the software is used over a network, it doesn't prevent its use in web services (AGPL FAQ). It ensures that all users, even those accessing the software remotely, benefit from improvements.

Lesser Copyleft Licenses - Sharing Core Components

Alex uses your Lego gears in a complex clock he builds. He doesn't have to share the design of his clock, but when he improves the gears to be more efficient, he shares those improvements with you. You both benefit from better gears, while Alex's clock design remains his own.

Suppose you build a special set of Lego gears and say to Alex,
You can use my gears in your creations, and if you improve the gears themselves, please share those improvements. But you don't have to share your entire creation. This encourages Alex to use and enhance the gears while allowing him to keep his own designs private.

This is like the GNU Lesser General Public License (LGPL). It's often used for software libraries. If someone modifies the library, they must share those changes under the LGPL, but they can use the library in their own software without having to release their entire program's source code.

People sometimes think the LGPL allows them to ignore copyleft requirements entirely. However, any modifications to the LGPL-licensed components must still be shared under the same license (LGPL FAQ).

Middle Ground Licenses - Balancing Sharing and Privacy

Alex uses your Lego engine in his custom car model. He tweaks the engine for better performance and shares those improvements with you. However, he keeps his car design private. This way, the core engine gets better for both of you, while Alex's unique work remains his.

Consider if you say to Alex, You can use my special Lego engine in your own creations, but if you change the engine itself, you need to share those changes with me. However, you can keep the rest of your creation to yourself. This way, the core part stays open, but Alex can keep his own creations private.

This is like the Mozilla Public License (MPL). It's a compromise between copyleft and permissive licenses. It requires that any changes to the original code are shared under the same license but allows new code that is added to remain under a different license.

Some think the MPL forces them to open source their entire project. In fact, only modifications to MPL-licensed code need to be shared, not your entire codebase (MPL FAQ). This allows for collaboration on core components while protecting proprietary elements.

Licenses Focusing on Collaboration and Protection

Alex enhances your Lego robot with voice control. He shares his improvements and includes a note about his changes. Because of your agreement, you both feel safe using and modifying the robot without fear of legal issues, leading to more innovation.

Imagine you say to Alex, You can use my Lego robot and change it if you like, but let's agree not to argue over who built which part. Also, please tell me about any big changes you make, and don't sue me over ideas used in this robot. This helps prevent disagreements and encourages transparency and cooperation.

This is similar to the Apache License 2.0. Others can use and modify the code, but there are rules to prevent disputes, like not suing each other over patents (which are like ideas or inventions).

Some believe the Apache License is too restrictive because of its patent clauses. In reality, these clauses are there to protect users from patent litigation, making it safer to use the software (Apache License FAQ).

Adding Some Fun

Sometimes, people create licenses that are a bit humorous to make a point or just for fun. Imagine you just tell Alex, Do whatever you want with my Lego That's it—no rules at all.

This is like the Do What the Fuck You Want to Public License (WTFPL). It's a very permissive license that allows anyone to do anything with the code. While it's humorous, it's important to note that such licenses may not be legally robust in all jurisdictions. Because it's so informal, some think the WTFPL isn't a real license. However, it is recognized by the Open Source Initiative, though its legal enforceability can be questionable.

What Happens If You Switch Licenses Mid-Game

Imagine you've been sharing your Lego creations with Alex under one set of rules, and partway through, you decide to change them. Perhaps you initially said to Alex, Do whatever you want but now you want him to share his improvements. After seeing amazing things Alex has done with your Lego creations without sharing back, you decide to change your rules to require sharing improvements. For future creations, Alex now knows he needs to share changes. But for the creations already shared, the old rules still apply, and he can keep his modifications private if he wishes.

I actually went through this experience with my open-source project, KFTray. When I first started building it, I was like someone who just wanted to share their Lego creation with friends—I chose the MIT license because it was simple and permissive. It was like saying, "Here's my Lego set, do whatever you want with it!"

But as the project grew and I saw how others were using it, I realized I wanted to ensure that improvements would be shared back with the community. It's like noticing that while Alex was making amazing modifications to your Lego creation, those improvements weren't being shared with you who might benefit from them. So, I decided to switch to the GPL 3.0 license through this pull request — essentially changing the rules to say, "You can still play with and modify these Lego pieces, but now you need to share your improvements with me."

In software, changing the license of your project is possible but can be complicated. If you're the sole owner of the code, you can relicense it as you wish. However, if others have contributed, you'll need their permission to change the license on their contributions.

Some think they can unilaterally change the license without affecting existing users. While you can change the license for future versions, the old versions remain under the original license, and users can continue to use them under those terms (Changing a License).

Mixing and Matching - License Compatibility

Sometimes, you want to combine your Lego spaceship with Alex's Lego castle to make an even bigger creation. But if you have different rules for sharing, it might get complicated. You want to merge your GPL-licensed Lego spaceship with Alex's permissively licensed castle. To share the combined creation, you both need to agree on a license that respects both sets of rules. Otherwise, you might not be able to share the new creation with others.

In software, combining code with different licenses can be tricky. Some licenses are compatible, meaning the code can be combined without issues. Others are incompatible, and combining them could lead to legal problems.

Many think that all open source licenses are compatible. In reality, licenses like the GPL are not compatible with some permissive licenses when it comes to distributing combined works (GPL Compatibility). It's important to understand the licenses involved to avoid accidental misuse.

Why Licenses Matter - Fair Play and Collaboration

Licenses help protect creators and guide users. They set clear expectations, fostering an environment where everyone knows how they can use, modify, and share creations.

Some people think licenses are unnecessary or just legal jargon. But without clear licenses, users might unknowingly break laws, and creators might not have their rights respected (The Importance of Open Source Licenses).

By understanding these licenses, we can choose how we want to share our work and collaborate with others. Whether we're like Alex, deciding how to share our Lego spaceship, or someone using others' creations, knowing the rules helps us contribute to a community where everyone can create, improve, and enjoy together.

Both Lego and Code

Licenses are like the rules we agree on when sharing our Lego creations. They help us play fairly, encourage sharing, and protect each other. Remember, just like sharing your Lego creations can lead to new and exciting builds you might not have imagined, sharing software under open source licenses can lead to amazing collaborations that benefit everyone.

Building Together

Open source is all about collaboration and shared growth. By respecting the licenses and the intentions behind them, we foster an environment where creativity thrives. It's like a big playground where everyone brings their toys, and together, we build something greater than any one of us could alone.

So next time you're using or creating open source software, think of it as sharing your Lego creations. Set the rules that feel right to you, understand others' rules, and enjoy the process of building something amazing together.

Local Kubernetes Cluster - External traffic without Ingress Using Kftray

Henrique Cavarsan — Tue, 01 Oct 2024 01:42:01 +0000

Hello. In this post, I'll show you how to set up a local Kubernetes cluster using Kind, Terraform, and Kftray. We'll keep all services inside the cluster, avoiding the need for ingress controllers or exposing services like NodePort or LoadBalancer. I'll also walk you through the Terraform code used in this setup.

Terraform code used in this Blog Post: https://github.com/hcavarsan/kftray-k8s-tf-example

Why Keep Services Inside the Cluster?

Exposing services externally can add complexity and potential security risks. For local development or secure environments, it's often better to keep everything internal. By using kubectl port-forward and automating it with Kftray, we can access services running inside the cluster without exposing them to the outside world.

Tools You'll Need

Before starting, make sure you have the following installed:

Docker
Terraform (v1.9.5)
Kftray (you can choose between the GUI or TUI version)

Cloning the Repository

First, clone the repository that contains the Terraform code:

git clone https://github.com/hcavarsan/kftray-k8s-tf-example
cd kftray-k8s-tf-example/terraform

Understanding the Terraform Code

The Terraform code in this repository automates the following:

Creates a Kind Kubernetes cluster.
Deploys Helm charts for Argo CD, Prometheus, Alertmanager, Grafana, and Jaeger.
Sets up service annotations for Kftray to auto-import port-forward configurations.

Project Structure

Here's how the project is organized:

kftray-k8s-tf-example
├── terraform
│   ├── helm.tf
│   ├── outputs.tf
│   ├── locals.tf
│   ├── providers.tf
│   ├── variables.tf
│   ├── templates
│   │   ├── argocd-values.yaml.tpl
│   │   ├── grafana-values.yaml.tpl
│   │   ├── jaeger-values.yaml.tpl
│   │   └── prometheus-values.yaml.tpl
│   └── kind.tf
├── Makefile
├── docs
│   ├── kftray.gif
│   └── kftui.gif
└── README.md

providers.tf

This file specifies the Terraform providers we'll use:

terraform {
  required_version = ">= 1.0.0"

  required_providers {
    kind = {
      source  = "tehcyx/kind"
      version = "0.4.0"
    }
    helm = {
      source  = "hashicorp/helm"
      version = ">= 2.0.0"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = ">= 2.0.0"
    }
    template = {
      source  = "hashicorp/template"
      version = ">= 2.0.0"
    }
  }
}

provider "kind" {
}

provider "kubernetes" {
  config_path = kind_cluster.default.kubeconfig_path
}

provider "helm" {
  kubernetes {
    config_path = kind_cluster.default.kubeconfig_path
  }
}

kind: Manages Kind clusters.
kubernetes: Interacts with the Kubernetes cluster.
helm: Deploys Helm charts.
template: Processes template files.

variables.tf

Defines variables used in the Terraform configuration:

variable "cluster_name" {
  description = "Name of the Kind cluster"
  type        = string
  default     = "kftray-cluster"
}

variable "kubernetes_version" {
  description = "Version of the Kind node image"
  type        = string
  default     = "v1.30.4"
}

variable "kubeconfig_dir" {
  description = "Directory to store the kubeconfig file"
  type        = string
  default     = "~/.kube"
}

# Chart versions
variable "argocd_chart_version" {
  description = "Version of the Argo CD Helm chart"
  type        = string
  default     = "5.19.12"
}

variable "prometheus_chart_version" {
  description = "The version of the Prometheus chart to deploy."
  type        = string
  default     = "25.27.0"
}

variable "grafana_chart_version" {
  description = "The version of the Grafana chart to deploy."
  type        = string
  default     = "8.5.0"
}

variable "jaeger_chart_version" {
  description = "The version of the Jaeger chart to deploy."
  type        = string
  default     = "3.3.1"
}

kind.tf

Creates the Kind cluster:

resource "kind_cluster" "default" {
  name            = var.cluster_name
  node_image      = "kindest/node:${var.kubernetes_version}"
  kubeconfig_path = pathexpand("${var.kubeconfig_dir}/kind-config-${var.cluster_name}")
  wait_for_ready  = true

  kind_config {
    kind        = "Cluster"
    api_version = "kind.x-k8s.io/v1alpha4"

    node {
      role = "control-plane"

      extra_port_mappings {
        container_port = 80
        host_port      = 80
        protocol       = "TCP"
      }
    }

    node {
      role = "worker"
    }
  }
}

name: Cluster name.
node_image: Kubernetes version.
kubeconfig_path: Where to store the kubeconfig file.
wait_for_ready: Wait until the cluster is ready.
kind_config: Custom Kind configuration.

locals.tf

Defines local variables and service configurations:

locals {
  services = {
    argocd = {
      namespace  = "argocd"
      repository = "https://argoproj.github.io/argo-helm"
      chart      = "argo-cd"
      version    = var.argocd_chart_version
      kftray = {
        server = {
          alias       = "argocd"
          local_port  = "16080"
          target_port = "http"
        }
      }
    }
    # ... other services ...
  }

  services_values = {
    for service_name, service in local.services :
    service_name => templatefile("${path.module}/templates/${service_name}-values.yaml.tpl", {
      kftray = service.kftray
    })
  }
}

services: A map of services to deploy.
kftray: Port-forward configurations for Kftray.
services_values: Processes Helm values templates for each service.

helm.tf

Deploys the services using Helm:

resource "helm_release" "services" {
  depends_on = [kind_cluster.default]
  for_each         = local.services
  name             = each.key
  namespace        = each.value.namespace
  create_namespace = true
  repository       = each.value.repository
  chart            = each.value.chart
  version          = each.value.version

  values = [
    local.services_values[each.key]
  ]
}

for_each: Iterates over each service.
name: Release name.
namespace: Kubernetes namespace.
repository: Helm chart repository.
chart: Helm chart name.
version: Chart version.
values: Custom values for the Helm chart.

templates/

Contains Helm values templates for each service (e.g., argocd-values.yaml.tpl). These templates inject the Kftray annotations into the service definitions.

outputs.tf

Defines outputs for the Terraform run:

output "endpoint" {
  description = "API endpoint for the Kind cluster."
  value       = kind_cluster.default.endpoint
}

output "kubeconfig" {
  description = "Kubeconfig file for the Kind cluster."
  value       = kind_cluster.default.kubeconfig
  sensitive   = true
}

output "credentials" {
  description = "Credentials for authenticating with the Kind cluster."
  value = {
    client_certificate     = kind_cluster.default.client_certificate
    client_key             = kind_cluster.default.client_key
    cluster_ca_certificate = kind_cluster.default.cluster_ca_certificate
  }
  sensitive = true
}

Applying the Terraform Configuration

To apply the Terraform configuration and set up the cluster, run:

make apply

This will:

Initialize Terraform.
Create the Kind cluster.
Deploy the Helm charts.
Set up the service annotations.

Installing Kftray

Go to the Kftray GitHub page and follow the installation instructions for your operating system.

Importing Port-Forward Configurations into Kftray

Using Kftray GUI

Open Kftray and click the tray icon to open the main window.
Click the menu icon at the bottom left corner.
Select "Auto Import."
Click "Set kubeconfig" and choose the kubeconfig file created by Terraform (usually ~/.kube/kind-config-kftray-cluster).
Select the context kftray-cluster from the dropdown menu.
Click "Import" to load the port-forward settings.

After importing, you can start port forwarding by toggling the switch next to each service or by clicking "Start All."

Using Kftui (Terminal Interface)

Set the KUBECONFIG environment variable:

   export KUBECONFIG="~/.kube/kind-config-kftray-cluster"

Start Kftui:

   kftui

Press Tab to access the top menu and select "Auto Import."
Press Ctrl+A to select all configurations.
Press F to start all port forwards.

Accessing Your Services Locally

With port forwarding set up, you can access your services on your local machine:

Argo CD: http://localhost:16080
Prometheus: http://localhost:19090
Alertmanager: http://localhost:19093
Grafana: http://localhost:13080
Jaeger: http://localhost:15090

Custom Kftray Settings

Adjusting Kftray Port Forwarding Settings

To customize how Kftray forwards ports, edit the locals.tf file:

locals {
  services = {
    argocd = {
      kftray = {
        server = {
          alias       = "argocd"
          local_port  = "16080"
          target_port = "http"
        }
      }
    }
    # Other services...
  }
}

alias: The name displayed in Kftray.
local_port: The port on your machine to access the service.
target_port: The service's port or port name inside the cluster.

Cleaning Up

If you want to destroy the cluster and remove all resources, run:

make destroy

This will tear down the cluster and delete all the resources created by Terraform.

Conclusion

By keeping all services inside the cluster and using Kftray for port forwarding, we create a simpler and more secure environment. This setup is useful for local development and situations where you want to avoid exposing services externally.

Feel free to explore and modify the Terraform code to suit your needs. If you have any questions or need help, feel free to reach out.

Thanks for reading. You can find more of my work or get in touch on GitHub.

Debugging HTTP Traffic in kubectl port-forward with KFtray v0.11.7

Henrique Cavarsan — Fri, 14 Jun 2024 15:01:40 +0000

KFtray is a application that can be integrated into the system tray for easy interaction with kubectl port-forward commands. A additional feature has joined recently in new version 0.11.7, one that can make HTTP traffic traces logs; this is an new method that simplifies debugging. This article provides a short guide on how to get started with the new feature.

New in v0.11.7

Toggle HTTP Logs: Easily enable/disable HTTP logs for configurations, saved in $HOME/.kftray/http_logs/{config_id}_{local_port}.
Clean Logs Folder: New button to tidy up the logs folder.
Logging Controls: Buttons to turn HTTP logging on or off for each configuration.
Open Logs with Default Editor: Icon button to open HTTP logs with your default OS text editor.
Trace IDs for Requests and Responses: Each request and response in the log has the same trace ID to help identify linked requests and responses when handling multiple parallel requests.
Better Connection Reliability: Improvements in the KFtray server and desktop client.
Smaller Bundle Sizes: More efficient installation.

Using the New Feature - HTTP Traffic Logging

To utilize the new HTTP traffic logging feature, ensure you have the latest version of KFtray installed. Visit the GitHub releases page and download the latest version of KFtray for your operating system. Follow the installation instructions specific to your OS to complete the setup.

Once installed, Ensure the version number displayed in the logo icon tooltip matches the latest release v0.11.7.

Step 1: Open KFtray

Launch KFtray by clicking its icon or typing kftray in the terminal if you installed it using Homebrew..This will open the main interface when you click the system tray icon, where you can manage your configurations.

Step 2: Turn On HTTP Logging

Open Settings: Click the KFtray icon in your system tray and select the configuration panel from the menu.
Start Port Forward: Toggle the switch button to enable the configured port forwarding.
Pick a Configuration: In the same row of the switch button, click the hamburger icon to open the configurations from the forwarded port.
Enable Logging: Locate the "Enable HTTP Logging" and click it to turn on HTTP logging for that configuration.

Step 3: View HTTP Logs

Find Logs: HTTP logs are automatically saved in the directory $HOME/.kftray/http_logs/{config_id}_{local_port}. Each log file is named based on the configuration ID and local port for easy identification.
Open Logs: To view the logs, click the log icon button next to your configuration. This will open the log file in your default text editor, allowing you to inspect the HTTP requests and responses.
Trace IDs: Each request and response in the log has the same trace ID, making it easier to identify linked requests and responses when handling multiple parallel requests.

HTTP Logs Sample

  cat $HOME/.kftray/http_sniff/1_8080.log

  ----------------------------------------
  Trace ID: 5525d312-5582-46ad-85d1-0fd3710f824e
  Request at: 2024-06-13T15:34:09.756706+00:00
  Method: GET
  Path: /json
  Version: 1

  Headers:
  Host: 127.0.0.1:8081
  Connection: keep-alive
  sec-ch-ua: "Not/A)Brand";v="8", "Chromium";v="126", "Google Chrome";v="126"
  sec-ch-ua-mobile: ?0
  sec-ch-ua-platform: "macOS"
  Upgrade-Insecure-Requests: 1
  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
  Sec-Fetch-Site: none
  Sec-Fetch-Mode: navigate
  Sec-Fetch-User: ?1
  Sec-Fetch-Dest: document
  Accept-Encoding: gzip, deflate, br, zstd
  Accept-Language: en-US,en;q=0.9,pt;q=0.8


  Body:
  <empty>

  ----------------------------------------
  Trace ID: 5525d312-5582-46ad-85d1-0fd3710f824e
  Response at: 2024-06-13T15:34:09.901304+00:00
  Took: 144 ms
  Status: 200

  Headers:
  Access-Control-Allow-Credentials: true
  Access-Control-Allow-Origin: *
  Content-Length: 421
  Content-Type: application/json; encoding=utf-8
  Date: Thu, 13 Jun 2024 15:34:10 GMT


  Body:
  {
    "slideshow": {
      "author": "Yours Truly",
      "date": "date of publication",
      "slides": [
        {
          "title": "Wake up to WonderWidgets!",
          "type": "all"
        },
        {
          "items": [
            "Why <em>WonderWidgets</em> are great",
            "Who <em>buys</em> WonderWidgets"
          ],
          "title": "Overview",
          "type": "all"
        }
      ],
      "title": "Sample Slide Show"
    }
  }

Step 4: Clean Logs Folder

To manage disk space and keep your logs organized, you can clean the logs folder and check the size of the logs folder from kftray.

Open Main Menu: Click the system tray icon to open the main window, then click the hamburger icon in the bottom-left corner. You should see a button Prune Logs (0.00 MB) that displays the size of the HTTP logs folder.
Prune Logs: Click the Prune Logs button to remove all the HTTP log files from the logs folder and reclaim disk space.

Real-World Use Cases

Debugging CLI Tools

When using CLI tools that abstract HTTP calls, such as LocalStack, it can be challenging to debug the underlying HTTP requests and responses. HTTP logging in KFtray can help you capture and analyze these interactions.

Example: If you're using a CLI tool like LocalStack to simulate AWS services locally, enable HTTP logging for the configurations that interact with LocalStack. The logs will capture all HTTP requests and responses made by the CLI tool, including trace IDs to link related requests and responses. This makes it easier to debug issues and understand the behavior of the CLI tool.

Save History of HTTP Requests and Don't Lose Made Requests

By enabling HTTP logging, you can save a history of all HTTP requests and responses. This ensures that you don't lose any made requests, which is especially useful for debugging and auditing purposes.

Example: If you need to review past interactions or troubleshoot issues that occurred previously, the saved logs will provide a complete history of HTTP traffic, including trace IDs to link related requests and responses.

Fixing Microservices Issues

When developing a microservice architecture, use HTTP logging to view detailed request and response data. This helps identify issues in interactions between services.

Example: If a service interaction fails intermittently, enable HTTP logging for the configurations involved. Use the logs to pinpoint the problem, such as incorrect request parameters or unexpected response formats. The trace IDs will help you link related requests and responses.

Security Audits

Capture and review HTTP traffic logs to ensure no sensitive data is exposed in requests or responses. This is crucial for maintaining security compliance.

Example: Enable HTTP logging for configurations handling sensitive data. Regularly review the logs to verify that no private information is being leaked. The trace IDs will help you track the flow of sensitive data through your system.

Solving Intermittent Problems

Capture HTTP traffic during the occurrence of intermittent issues to find patterns or anomalies that may be causing the problems.

Example: Users report sporadic issues with your web application. Enable HTTP logging for the related configurations and capture traffic during the problem periods. Analyze the logs to identify any patterns or anomalies. Use the trace IDs to correlate requests and responses during the issue periods.

Boosting Performance

Monitor HTTP logs to identify slow endpoints and optimize the performance of your application.

Example: If certain endpoints are slow, enable HTTP logging for those configurations. Use the logs to identify the bottlenecks and optimize the endpoints for better performance. Trace IDs will help you follow the request-response cycle and pinpoint delays.

Wrap-Up

The new logging of HTTP traffic in KFtray v0.11.7 takes the work out of debugging and simplifies it. Turn logging on for your configurations and you'll be fixing issues in minutes. Trace IDs enable easy request and response correlation even when handling multiple requests in parallel.

Star us on GitHub ⭐

Quick Demo

This video demonstrates the complete flow of this new feature.

Kubectl Port-forward Flow Explained

Henrique Cavarsan — Mon, 15 Apr 2024 15:08:27 +0000

Introduction

Recently, I joined a discussion about how the kubectl port-forward command works, which caught my attention because I have an app that improves some aspects of the native kubectl port-forward. I made a public Mermaid chart to show the complete process of executing this command. I included everything from the authentication phase to sending a request through localhost that goes to the target pod via SPDY.

I noticed this topic often comes up on various social networks, so I decided to write this article to share the diagram and explain the steps involved. I had two main reasons for writing this article:

To share this information with those who are interested, especially since the official documentation doesn't cover this process in one place, making it hard to quickly get a full picture.
To have a reference for myself for future use, so I can look back at this article when needed :D

The diagram might be updated after its release to add more details or correct any mistakes I might have made (it happens :D). Feel free to point out any errors or add information if you find something wrong ;)

You can view and edit the full diagram here: Mermaid Link

Sequence Diagram Explained

Full Mermaid SVG Link

I will start by explaining each step in the diagram, grouped into 5 sections: Initialization, Authentication & Authorization, Information Retrieval for Pod, Port-forwarding Session Establishment, Configuring iptables for Port Forwarding and SPDY Session for Port Forwarding

Initialization

The user initiates the port-forwarding process by executing kubectl port-forward -n <namespace> <pod-name> <local-port>:<pod-port> via the CLI (Command-Line Interface).

Authentication & Authorization

Upon receiving the command, the CLI sends a request to the Kubernetes API server to authenticate the user's tokens and verify permissions. This involves an initial connection establishment with a Bearer Token. The API server then verifies the token's validity and checks if the user has authorization to access the specified pod.

Information Retrieval for Pod

To proceed with port-forwarding, the CLI retrieves essential details about the target pod by sending a GET request to the Kubernetes API server. Once received,

Port-forwarding Session Establishment

The CLI initiates the port-forwarding session by sending a POST request to the Kubernetes API server, requesting the establishment of a port-forwarding connection for the specified pod. Upon receiving the request, the API server switches protocols to Websocket/SPDY, establishing a persistent connection with multiplexing capabilities.

Configuring iptables for Port Forwarding

The Kubernetes API server instructs the Kubelet to configure iptables for port-forwarding. The Kubelet sets up iptables rules to redirect traffic from the specified pod port to the designated external port (local port in kubectl)

SPDY Session for Port Forwarding

With the port-forwarding session established, the user interacts with the pod's application by sending requests through the Websocket/SPDY stream. The CLI wraps the user's request in a Websocket/SPDY frame, forwarding it to the Kubernetes API server. The API server then forwards the request to the Kubelet, which transmits it to the pod's port. The pod processes the request internally and responds, initiating a response flow back to the user through the established Websocket/SPDY session.

Feel free to edit the Mermaid chart here: Mermaid Live Editor

Conclusion

This article explains the kubectl port-forward command, detailing each step from starting up and logging in to transferring data. It covers authentication, authorization, and the SPDY connection to show how it works in Kubernetes.

While this article is meant to inform and not to promote, I'd like to share a link to kftray, a project I developed that adds new features and improvements to kubectl port-forward. If you're interested, you can check out kftray on GitHub here: kftray on GitHub.

Kubernetes Debugging: Handling Multiple kubectl port-forward from Tray

Henrique Cavarsan — Thu, 28 Mar 2024 01:49:15 +0000

As a developer working with Kubernetes, I often find myself with multiple port-forward open sessions to debug pods across namespaces. Keeping track of all those terminals can get chaotic quickly. To help streamline my debugging workflow, I created an open-source tool called KFTray that centralizes all your port forwards in a system tray. In this post, I demonstrate how can save developer time by comparing workflows with and without it.

The Pain of Kubernetes Debugging with Kubectl Port Forward

As an SRE, one of my primary responsibilities is debugging Kubernetes applications and infrastructure. The go-to tool for debugging pods in Kubernetes is kubectl port-forward. However, this utility has several limitations that often make the debugging process tedious and frustrating.

Lack of Auto-Reconnect for Unstable Connections
The kubectl port-forward command does not automatically reconnect if the connection is interrupted for any reason. This means if there is an issue with the network or Kubernetes API server, the port forward will stop working, and I have to manually restart it. For debugging unstable applications, this missing feature results in a poor experience and loss of productivity.
No UDP Support
Kubectl port-forward only supports TCP and does not natively support UDP. Many applications rely on UDP, so without support for UDP forwarding, debugging them is very difficult. We often have to modify applications to use TCP instead of UDP just for debugging purposes, which is far from ideal.
Single Pod Forwarding Only
The kubectl port-forward command can only forward ports for a single pod at a time. When debugging complex, multi-pod applications, this means I frequently have to open multiple terminal tabs to port forward to each pod individually. This process is tedious, difficult to manage, and negatively impacts productivity during debugging sessions.
Difficulty Keeping Configurations in Sync
On our team, we have port forwarding configurations defined in a shared Git repository so we can standardize them across projects. However, with kubectl, the only way to use these shared configurations is to manually download them and run them locally. This makes it difficult to keep everyone's configurations in sync and up-to-date.

Introducing KFtray: A Developer Tool for Kubernetes

As a developer working with Kubernetes, managing multiple port forwards for debugging applications can quickly become tedious and time-consuming. To simplify this process, I created KFtray, an open-source system tray application that provides a user-friendly interface for handling Kubernetes port forwarding.

Simplified Port Forward Management
KFtray allows developers to easily start, stop, and manage multiple port forwarding configurations simultaneously through an intuitive interface. Users can save configurations locally or sync them with a GitHub repository for team collaboration. KFtray automatically restarts pods as needed to maintain service continuity in the event of pod failure, improving reliability.
Customized Configuration
Developers can customize KFtray to use a specified local IP address instead of the default localhost for port forwarding. They can also enable TCP/UDP proxy forwarding through Kubernetes for additional flexibility. KFtray uses each operating system's keyring to securely store confidential information like API keys.
Staying Up-to-Date with Git Synchronization
For teams collaborating on Kubernetes applications, keeping port forwarding configurations in sync can be challenging. KFtray addresses this through an optional Git synchronization feature. Developers can connect KFtray to a GitHub repository containing their port forwarding configurations. KFtray will then automatically pull the latest configurations from that repository on an adjustable polling schedule.
Improved Productivity
By simplifying the management of Kubernetes port forwarding, KFtray aims to make developers more productive. No longer do they have to manually restart pods or switch between multiple terminal windows to handle port forwarding. KFtray provides a single interface to control all their port forwarding needs.
Keep your configurations updated with Github Sync
KFtray allows developers to easily store and manage port forward configurations from local files or GitHub repositories. This means users can save a configuration once and reload it whenever needed, reducing repetitive work. Developers can also share configurations with team members by committing them to a GitHub repo.
Simultaneous Port Forwards
A key pain point KFtray solves is the ability to run multiple port forwards simultaneously. Without a tool like KFtray, developers have to manually run each port forward separately in their terminal. KFtray handles running all port forwards in the background, freeing up the developer’s terminal. This is especially useful when debugging microservice-based applications that have many component services.
Convenient System Tray
KFtray runs in the system tray, providing an easy way to manage all port forwards in one place. From the system tray menu, developers can start, stop, restart or remove port forwards. KFtray also displays the status of each port forward, indicating if it is running or stopped. This convenient UI enhances productivity by giving developers quick access to manage and monitor their port forwards.

A Case Study: Debugging Microservices With and Without KFtray

As a developer focused on building microservices, I found the debugging process to be tedious and time-consuming. Each microservice has its own deployment, necessitating a separate port forward for debugging. Without an efficient tool to manage multiple port forwards, significant time was lost setting up and keeping configurations up to date.

The Situation Before

Prior to using KFtray, I had to manually run a kubectl port-forward command for each microservice I wanted to debug. If a pod restarted, the port forward would need to be re-established, causing further delays. When code was updated, the port forward configurations had to be manually updated to match, requiring diligent version control. Overall, managing the debugging infrastructure for microservices was inefficient and distracting.

A New Approach

KFtray simplified the debugging workflow by allowing me to define port forward configurations for each microservice in a central repository. With a single click, KFtray establishes all required port forwards, freeing me to focus on debugging my code. KFtray automatically reconnects port forwards when pods restart, and stays up-to-date with configuration changes through Git version control.

Get Started

Installation

KFtray is available for macOS and Linux users via Homebrew, and directly from the GitHub releases page for other systems. Here's how you can get started:

For macOS and Linux:


brew tap hcavarsan/kftray

brew install --HEAD kftray

For other systems, visit the GitHub releases page for downloadable binaries.

Configuring Your First Port Forward

In a few simple steps, you can configure your first port forward:

Launch the application
Open the configuration panel from the tray icon
Add a new configuration:

*   Give it a unique alias and set if you want to set the alias as domain to your forward
*    Indicate if the configuration is for a port forward for a service (common use) or a proxy (port forward to an endpoint via a Kubernetes cluster).
*   Specify the Kubernetes context
*   Define the namespace housing your service
*   Enter the service name
*   Choose TCP or UDP
*   Set the local and remote port numbers
*   Configure a custom local IP address (optional)

Activate Your Configuration: With your configuration saved, simply click on the switch button in the main menu to start the port forward in a single por forward or in Start All to start all configurations at the same time .

Demonstration:

Export configurations to a JSON file

Open the main menu in the footer
Select the Export Local File option
Choose a file name and location to save the JSON file
The JSON file will contain all your current configurations

You can then import this JSON file at any time to restore your configurations.

Example Json configuration File:

[
 {
  "service": "argocd-server",
  "namespace": "argocd",
  "local_port": 8888,
  "remote_port": 8080,
  "context": "test-cluster",
  "workload_type": "service",
  "protocol": "tcp",
  "remote_address": "",
  "local_address": "127.0.0.1",
  "alias": "argocd",
  "domain_enabled": true
 }
]

Sharing the configurations through Git

now, with the local json saved, you can share your configurations with your team members by committing the JSON file to a Github repository. This allows for easy collaboration and synchronization of KFtray configurations across your team.

To import and sync your github configs in kftray:

Open the application's main menu
Select the button with github icon in the footer menu
Enter the URL of your Git repository and path containing the JSON file
If your GitHub repository is private, you will need to enter the private token. Credentials are securely saved in the SO keyring (Keychain on macOS). Kftray does not store or save credentials in any local file; they are only stored in the local keyring.
Select the polling time for when Kftray will synchronize configurations and retrieve them from GitHub.
KFtray will now sync with the Git repository to automatically import any new configurations or changes committed to the JSON file.

This allows you to quickly deploy any port forward changes to all team members. And if someone on your team adds a new configuration, it will be automatically synced to everyone else's KFtray.

Demonstration:

Share Your Thoughts: Help Us Enhance KFtray with Your Feedback!

We hope our app makes your work easier. Any ideas for improvement? We’re all ears!

Star us on Github ⭐

Kftray Website: https://kftray.app

🔥 Enhance Your Kubernetes Tools with KFtray 0.8.0's Latest Features

Henrique Cavarsan — Mon, 04 Mar 2024 00:35:13 +0000

Hey everyone!

Kftray is a small, open-source app designed to simplify managing multiple kubectl port forwards, especially for local development. This app is a menu bar GUI and is built using the Tauri framework - Rust for the backend and TypeScript for the frontend and can be found more information at https://kftray.app/

Just a quick update: KFtray has just been upgraded to version 0.8.0 🚀. This release is packed with features that will refine your development workflow and enhance your productivity when working with Kubernetes and multiples kubectl port forward.

⚡️ What's New in KFtray 8.0.0

The team has been hard at work and we've rolled out some exciting updates:

Git Time Polling Synchronization: Your projects will remain up-to-date effortlessly! The new polling feature allows you to adjust how frequently KFtray checks your repositories for changes, ensuring your kftray environment aligns with the latest commits in the git.
Enhanced Git Synchronization Slider: Fine-tune your Git sync frequency with the integration of a convenient slider. You're now in full control of the polling rate, perfect for conserving system resources or getting real-time updates depending on your needs.
Sync History Timestamps: With our improved tooltips, you'll have a clear and precise log of your synchronization timeline. Monitor when the last sync took place and plan for the next one with ease.

Custom Local Address Configuration: Say goodbye to the restrictions of localhost. Customize your development environment by setting up a local IP address that fits your project structure or network configuration.

Quick-access URL Icon: Navigate to your forwarded local URL in an instant. Our new icon in KFtray provides immediate access to your application in your default browser with just a click.

🚀 Ongoing Enhancements

Rest assured, we're not stopping here. Our commitment to refining git-based state management is ongoing, and we can't wait to share more enhancements with you in the near future.

🔍 Get Your Hands on the Latest Release

Curious to see the updates in action? We invite you to check out the latest release at: KFtray 0.8.0 Release.

We value your feedback and are excited to see how these new features help you in your Kubernetes development journey. Stay tuned for more updates, and happy coding!

Managing multiple kubectl port-forward configurations and sharing them via Git 📦

Henrique Cavarsan — Tue, 27 Feb 2024 22:21:55 +0000

kubectl port-forward is an invaluable tool for developers working with Kubernetes, allowing for the exposure of local services through a tunnel. However, as the number of services grows, this manual method can become cumbersome. Common issues like terminal lock-up, tunnels lost after pod termination, and lack of support for UDP services can occur.

Introducing Kftray

To overcome these challenges, we created Kftray, a graphic interface application developed with Rust and TypeScript using the Tauri framework. Kftray offers a more efficient way to manage port-forward tunnels in a Kubernetes environment.

Key Features

Configuration Management: Easily add, start, and stop multiple port-forward configurations.
Autocomplete: Reduces the need to remember complex commands thanks to an autocomplete feature.

Configuration Export: Export your settings to a JSON file and keep a backup for quick restorations.

Json Example:

[
  {
    "alias": "consul-ui",
    "context": "kind-7",
    "local_port": 8500,
    "namespace": "consul",
    "protocol": "tcp",
    "remote_port": 8500,
    "service": "consul-ui",
    "workload_type": "service"
  },
  {
    "alias": "redis-gcp",
    "context": "kind-6",
    "local_port": 26379,
    "namespace": "default",
    "protocol": "udp",
    "remote_address": "redis-prod.gcp.internal",
    "remote_port": 6379,
    "workload_type": "proxy"
  }
]

Solutions for Common Issues

Terminals Don't Get Locked: Kftray operates independently of kubectl and won't lock up terminals. An internal relay server allows UDP services to be port-forwarded over TCP.
Pod Failure Resilience: The application redirects traffic to new pods when the old ones fail, providing continuous connection.
Access to Non-Kubernetes Internal Services: Kftray can direct TCP traffic even for internal services not hosted on the Kubernetes cluster.

Git Sync Plus

The latest version of Kftray v0.7.1 introduces a new feature: synchronizing configurations with a GitHub repository. As soon as updates are made to the JSON configuration file, just one click is needed for Kftray to apply them.

Getting Started with Kftray

To try out Kftray, visit our GitHub repository and follow the instructions for downloading and installation: Github Kftray

Contributions Are Welcome

We invite the community to collaborate on the Kftray project. If you find bugs or have ideas for new features, feel free to contribute. Your participation is crucial for making Kftray even better! Github Kftray

we plan to release updates with new features like pooling for synchronization and the ability to add multiple configuration repositories. That's all for now! I hope you find Kftray helpful! 🚀🎉

If you do, please consider giving us a star on GitHub at Kftray. It really helps us! 🌟

KFtray: Manage Multiple kubectl Port Forwards with Ease from Your Menu Bar 🚀

Henrique Cavarsan — Fri, 16 Feb 2024 16:22:38 +0000

KFtray, the new open-source tool for Kubernetes users. It simplifies managing your kubectl port forwards from the menu bar. See why it could be useful for your toolkit:

Kubectl Pain Points 🚨

KFtray was developed with a clear objective in mind: simplifying the complexities associated with managing multiple kubectl port forwards, enhancing the stability of these connections, and filling in the capabilities that kubectl lacks. The motivation for KFtray stemmed from several identified issues:

Excessive Terminal Windows: Managing numerous kubectl port forwards can lead to a cluttered and unmanageable desktop environment, making efficient work challenging.
Unreliable Connections: The instability caused by pod failures can disrupt port forward connections, further complicated by the absence of UDP forwarding support in kubectl.

Why KFtray? ✅

KFtray aims to address these challenges by:

Simplifying the Workflow: It eradicates the clutter of numerous terminal windows, paving the way for a cleaner and more manageable working environment.
Ensuring Reliability: the app is designed to automatically re-establish connections when disruptions occur, maintaining a stable workflow regardless of pod status.
Expanding Capabilities: By incorporating UDP forwarding and proxy functionality, KFtray offers a more comprehensive set of tools than what kubectl alone provides.

Through these measures, KFtray seeks to enhance productivity and streamline the management of Kubernetes resources, making it a valuable tool for developers and system administrators alike.

Key Features 🌟

Reliable Port Forwarding: Ensures your services stay connected, even if disruptions occur.
Batch Forwarding: Initiate multiple port forwardings with a single action.
Bypass kubectl: Direct interaction with Kubernetes API for a smoother experience.
TCP & UDP Support: Compatibility with both protocol types for versatile service connections.

Easy Installation 🛠️

ou can directly download it from the GitHub releases page at https://github.com/hcavarsan/kftray/releases. But, for macOS and Linux users, installation via Homebrew is an option, check more details in repository README

Configurations Management🔧

Kftray stores configurations in a SQLite file in the user's home folder for easy export, import, and sharing the exported JSON file.

Get Started with KFtray ✨

KFtray offers simplicity for Kubernetes port forwarding tasks, presented in an easily accessible format. It's a practical tool for any Kubernetes user seeking a more manageable and effective port forwarding solution.

Share Your Thoughts: Help Us Enhance KFtray with Your Feedback! 🌟

We hope our app makes your work easier and gets more folks into Kubernetes. Any ideas for improvement? We’re all ears!

Star us on GitHub - ⭐ https://github.com/hcavarsan/kftray

Kftray - kubernetes port forward no menu bar!

Henrique Cavarsan — Fri, 16 Feb 2024 01:51:17 +0000

Introdução ao Kftray

uma aplicação no menu bar desenvolvida com Rust e React usando o framework Tauri, o app tem um proposito simples: simplificar a forma como executamos e gerenciamos multiplos kubectl port-forward no dia a dia, e também o kftray adiciona novos recursos em comparação com o tradicional kubectl port-forward. (mais detalhes nos proximos topicos)

KFtray

A principal missão do KFtray é simplificar o processo de gerenciamento de multipos kubectl port forward de clusters Kubernetes. Projetado com simplicidade e produtividade em mente, o app permite aos usuários iniciar e parar múltiplas configurações de redirecionamento de portas por meio de uma interface elegante e amigável. O app se destaca pela sua resiliência, operações com um clique e independência do kubectl, pois se conecta diretamente com a API do Kubernetes.

Mão na massa!

Configurar o KFtray é muito simples:

Configurando configurações de port-forward: A UI intuitiva permite adicionar e gerenciar facilmente as configurações port forward com campos para workload (Proxy ou Serviço), alias único, contexto do Kubernetes, namespace, service, remote address (para Proxy), protocolo (TCP/UDP) e portas locais/remotas.

Ativando os port forwards: Você pode iniciar um unico port forward com um simples clique ou lançar multipos forwards simultaneamente, tornando muito fácil gerenciar configurações complexas.

Gerenciando Configurações: O KFtray fornece opções para exportar/importar configurações como arquivos JSON, garantindo que você possa compartilhar ou fazer backup de suas configurações. Ele também salva as configurações de forma segura localmente em “$HOME/.kftray/configs.db”. Aqui está um exemplo do formato JSON esperado pelo KFtray:

[  
  {  
    "alias": "consul-ui",  
    "context": "kind-7",  
    "local_port": 8500,  
    "namespace": "consul",  
    "protocol": "tcp",  
    "remote_port": 8500,  
    "service": "consul-ui",  
    "workload_type": "service"  
  },  
  {  
    "alias": "redis-gcp",  
    "context": "kind-6",  
    "local_port": 26379,  
    "namespace": "default",  
    "protocol": "udp",  
    "remote_address": "redis-prod.gcp.internal",  
    "remote_port": 6379,  
    "workload_type": "proxy"  
  }  
]

Conexão de Redirecionamento de Porta Resiliente:

Resilient Port Forwarding Connection: O KFtray garante que seus serviços permaneçam acessíveis ao reconectar automaticamente a pods alternativos em execução, caso algum falhe..
Vários port forwards com Um Clique: Configure rapidamente múltiplas instâncias de port forward com um único clique
Independente do Kubectl: A interface direta do KFtray com a API do Kubernetes elimina a dependência do kubectl, proporcionando uma experiência mais suave e atendendo àqueles que preferem interfaces gráficas ao invés da linha de comando.
Suporte a Múltiplos Protocolos:: Expandindo além do TCP, o suporte do KFtray a múltiplos protocolos, incluindo UDP, permite acesso a uma variedade de serviços, tanto internos quanto externos aos seus clusters Kubernetes.

Conclusão

O KFtray visa melhorar a experiência de gerenciar multipos port forward de uma vez, oferecendo uma solução simples, eficiente e confiável. Seja para depuração de serviços ou acesso a recursos internos, o KFtray oferece a flexibilidade e confiabilidade necessárias em ambientes de desenvolvimento de ritmo acelerado.

Se você achou o KFtray util, considere nos dar uma estrela no GitHub em https://github.com/hcavarsan/kftray.

Se você encontrar algum problema ou tiver dúvidas sobre o KFtray, crie uma issue em nosso repositório !