kftray

Local Kubernetes Cluster with Automatic kubectl port-forward configurations using kftray

Henrique Cavarsan — Tue, 01 Oct 2024 01:48:51 GMT

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

Full Demo:

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-examplecd 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 versionsvariable "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.

]]>

Port Forward Transition from SPDY to WebSockets in Kubernetes 1.30

Henrique Cavarsan — Mon, 29 Apr 2024 21:37:54 GMT

Introduction

One of the changes in the latest Kubernetes version, 1.30 (Uwubnetes) is the transition from SPDY to websocket for some of the kubectl commands. Most of the updates get most of the attention, but this is no less important.

Understanding SPDY:

Google created SPDY to improve HTTP by speeding up webpage load times and enhancing security with a session layer. It allowed multiple data streams to be sent simultaneously, prioritized request values, and optimized communication by compressing headers. However, SPDY was deprecated in 2016 and replaced by HTTP/2, which is more advanced. Therefore, for technologies like Kubernetes that require better and standards communication methods, SPDY is no longer relevant.

Why WebSockets?

WebSockets use a bidirectional communication protocol over a single TCP connection, widely supported in web servers, proxies, and network gateways. This increases compatibility and communication performance for kubectl commands. Here are some points about WebSockets:

WebSockets allow for full-duplex communication, so it's very efficient to send and receive data. It requires no multiple connections, that would require handshakes.
This technology reduces overhead and allows for high-speed data exchanges, which is especially interesting for Kubernetes-related tasks.
WebSockets are protocol-independent so they may be used for communication over any full-duplex single-connection protocol, which will reduce latency and help in real-time command execution.
WebSockets keep a persistent connection and thus use resources more efficiently and cut the number of TCP connections used, in turn reducing the amount of network overhead.
The use of WebSockets fix issues that older protocols like SPDY had, and it's more compatible with modern web technologies.

The migration from SPDY to WebSockets in Kubernetes makes it much easier to communicate control messages, which will allow for better cluster management and stability.

Kep 4006

The SPDY protocol was deprecated in 2016. In 2023, a proposal was opened in the Kubernetes community to change the protocol for commands like port-forward, attach, exec, and portforward that use upgraded connections.

Link to proposal Link to issue

Implementation Overview:

WebSocket support in Kubernetes and kubectl starts with an HTTP handshake that upgrades the connection to a WebSocket, like as the SPDY. The WebSocket framing method provides improved technique for data framing for streams such as stdin, stdout, and stderr through framing with a channel identifier. This is an extension of the technique once used by SPDY through binary data framing.

As a fallback mechanism in case WebSocket support is not available on the server, a fallback to SPDY is utilized. The initial performance assessments demonstrated that WebSocket is as efficient as, or even a little better than, SPDY for standard kubectl operations, and continuing performance testing is intended to better performance across multiple use cases. There are many implications from this transition, including greater network compatibility in settings where strong proxy and firewall policies are in place, and better integration with external tools.

API server changes:

The API server now supports the WebSocket protocol by replacing SPDY with explicit headers to enable bidirectional streams. Additionally, the StreamTranslatorProxy has been added to help create WebSocket connections from clients to internal SPDY connections in Kubernetes.

The management of WebSocket frames is critical, especially for the occasional use of the ping/pong frames to keep the WebSocket connection alive. This feature was first introduced in an alpha version that one could use through the feature gate for port forwarding Websockets within the API server and a corresponding flag in kubectl.

Client (`kubectl`) Changes:

On the client side, it added an upgrade to WebSocket for port forwarding, along with signing, response processing, and data serialization and deserialization over the WebSocket. This gives the user the ability to enable WebSocket port forwarding through environment variables. To make this transition easy, kubectl has also introduced mechanisms to handle errors and reliability, with error handling during its alpha and beta phases, along with a fallback to SPDY in case the WebSocket connection fails to ensure that service continuity is not lost.

Websockets in `kubectl port-forward` with Kind

Setup Env

Before creating my environment, Docker, Kind, and Go have to be installed on the machine. All of these are needed for developing and deploying our Kubernetes cluster on our local machines. Let's set up the environment with Kubernetes 1.30.

Let's start by setting up the necessary environment variables and dependencies:

# Set Go environment variablesexport GOPATH=$HOME/goexport GOROOT=/usr/local/goexport PATH=$PATH:$GOROOT/bin:$GOPATH/bin# Create a directory for Kubernetes sourcemkdir -p $GOPATH/src/k8s.iocd $GOPATH/src/k8s.io# Clone the Kubernetes repositorygit clone https://github.com/kubernetes/kubernetes.gitcd kubernetes

Install Dependencies on Mac M1

For those uses Mac with an M1 chip:

brew install bashbrew install gnu-tar

Building the kubernetes and kubectl 1.30 image

To build the images and kubectl, we need to have Go 1.22 or later. Then, execute some commands:

# Checkout to the Kubernetes 1.30 releasegit checkout release-1.30# Build a node image using Kindkind build node-image# Build the kubectl in this versionmake kubectl KUBE_BUILD_PLATFORMS=darwin/arm64# kubectl artifact output path : $GOPATH/kubernetes/_output/dockerized/bin/darwin/arm64/kubectlchmod +x $GOPATH/kubernetes/_output/dockerized/bin/darwin/arm64/kubectl

Kind Cluster Configs

First, set up the kind cluster with 1.30 images by creating a config.yaml file with featureGates PortForwardWebsockets enabled:

kind: ClusterapiVersion: kind.x-k8s.io/v1alpha4featureGates:  "PortForwardWebsockets": truenodes:- role: control-plane  image: kindest/node:latest- role: worker  image: kindest/node:latest- role: worker  image: kindest/node:latest

Create the cluster

When you have your configuration file set up you can add the cluster with the following command:

# Change default kubeconfig path to have only with kind test clusterexport KUBECONFIG=~/.kube/kind-kindkind create cluster --name kind-1-30 --config config.yaml

Deploy a sample app

You can test your new WebSocket capability by deploying a simple application and using the cluster to connect by port forwarding:

git clone https://github.com/digitalocean/kubernetes-sample-apps.gitcd kubernetes-sample-appskubectl apply -k bookinfo-example/kustomize

Forward the Port Using WebSockets

Enable the WebSocket port forwarding :

export KUBECTL_PORT_FORWARD_WEBSOCKETS="true"$GOPATH/kubernetes/_output/dockerized/bin/darwin/arm64/kubectl -v6 port-forward svc/productpage -n bookinfo 9080:9080

Now, open http://localhost:9080/ in your browser. You should get responses from the echoserver.

Verifying WebSocket Port Forwarding

To confirm if WebSocket port forwarding is active, review the kubectl logs:

This is the log with SDPY (default):

I0422 17:32:50.963059   11299 round_trippers.go:466] curl -v -XPOST  -H "X-Stream-Protocol-Version: portforward.k8s.io" -H "User-Agent: kubectl/v1.31.0 (darwin/arm64) kubernetes/cae35db" 'https://192.168.68.109:6443/api/v1/namespaces/bookinfo/pods/productpage-v1-64c658687d-5bhsg/portforward'I0422 17:32:50.965663   11299 round_trippers.go:510] HTTP Trace: Dial to tcp:192.168.68.109:6443 succeedI0422 17:32:50.978422   11299 round_trippers.go:553] POST https://192.168.68.109:6443/api/v1/namespaces/bookinfo/pods/productpage-v1-64c658687d-5bhsg/portforward 101 Switching Protocols in 15 millisecondsI0422 17:32:50.978440   11299 round_trippers.go:570] HTTP Statistics: DNSLookup 0 ms Dial 2 ms TLSHandshake 0 ms Duration 15 msI0422 17:32:50.978444   11299 round_trippers.go:577] Response Headers:I0422 17:32:50.978448   11299 round_trippers.go:580]     Upgrade: SPDY/3.1I0422 17:32:50.978450   11299 round_trippers.go:580]     X-Stream-Protocol-Version: portforward.k8s.ioI0422 17:32:50.978453   11299 round_trippers.go:580]     Connection: Upgrade

This is the logs with Websocket enabled:

17:29:21.504179    7561 tunneling_dialer.go:75] Before WebSocket Upgrade Connection...I0422 17:29:21.504194    7561 round_trippers.go:466] curl -v -XGET  -H "Sec-Websocket-Protocol: SPDY/3.1+portforward.k8s.io" -H "User-Agent: kubectl/v1.31.0 (darwin/arm64) kubernetes/cae35db" 'https://192.168.68.109:6443/api/v1/namespaces/bookinfo/pods/productpage-v1-64c658687d-5bhsg/portforward'I0422 17:29:21.506351    7561 round_trippers.go:510] HTTP Trace: Dial to tcp:192.168.68.109:6443 succeedI0422 17:29:21.519936    7561 round_trippers.go:553] GET https://192.168.68.109:6443/api/v1/namespaces/bookinfo/pods/productpage-v1-64c658687d-5bhsg/portforward 101 Switching Protocols in 15 millisecondsI0422 17:29:21.519954    7561 round_trippers.go:570] HTTP Statistics: DNSLookup 0 ms Dial 2 ms TLSHandshake 4 ms ServerProcessing 8 ms Duration 15 msI0422 17:29:21.519958    7561 round_trippers.go:577] Response Headers:I0422 17:29:21.519962    7561 round_trippers.go:580]     Sec-Websocket-Accept: +AqmlgtoGPP/Rlfw6oAZMCN34SY=I0422 17:29:21.519964    7561 round_trippers.go:580]     Sec-Websocket-Protocol: SPDY/3.1+portforward.k8s.ioI0422 17:29:21.519966    7561 round_trippers.go:580]     Upgrade: websocketI0422 17:29:21.519968    7561 round_trippers.go:580]     Connection: UpgradeI0422 17:29:21.519973    7561 tunneling_dialer.go:85] negotiated protocol: portforward.k8s.io

The logs show that the protocol upgrade to SPDY via WebSocket was successful in Kubernetes 1.30

KEP Roadmap Port Forward over Websockets

Alpha Release (Kubernetes 1.30):

WebSocket support added. Feature enabled via the KUBECTL_PORT_FORWARD_WEBSOCKETS=true env var on the client side and PortForwardWebsockets alpha feature flag should be enabled on the API Server,.

Focus in the alpha phase would be testing from all perspectives, user feedback, and updating developer and user documentation for this alpha feature.

Beta Release(Target 1.31):

More extensive testing for performance fine-tuning, user feedback, and updated documentation, the documentation will be updated regularly with the changes during the beta phase improvements.

User community feedback will be the basis in making the feature stable and usable.

Stable Release (Target 1.32):

Ensure WebSocket support transitions from beta to stable with alpha feature flags removed and publish a deprecation notice to officially mark the transition away from SPDY-based port forwarding.

KEP Roadmap RemoteCommand over websockets (exec, cp, attach)

Beta release (Kubernetes 1.30):

WebSocket for RemoteCommand (exec, cp, attach) will be on by default. The feature gates to the client and server are expected to ensure that the SPDY replacement has as little impact on the user as possible.

The biggest emphasis here is on making the changes transparent to the user and, for those who are wary of this new implementation, will always have the choice to disable it.

Path to Stability:

Post 1.30 and leading up to the 1.32 release, the focus will be on refinement in WebSocket functionality, all aimed at reaching zero known critical bugs.

Conclusion

And thats all, folks. This hopefully explains the important protocol communication change in Kubernetes. I've had too many issues due to SPDY and lack of compatibility with new load balancers, proxies, etc., which was so complicated that I found myself at work. Now I see this migration from SPDY to WebSockets, so I'm a bit excited.

Looking forward, I'll let you know if there are any updates about this KEP

Also, maybe there'll be errors or misinformation in this post; I'm just human after all. Feel free to let me know if you find anything off on social media or post a comment here at the blog. Thanks!

]]>

Kubectl Port-forward Flow Explained

Henrique Cavarsan — Mon, 15 Apr 2024 02:12:50 GMT

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 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 SPDY stream.

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: How to Handle Multiple kubectl port-forward from your System Tray

Henrique Cavarsan — Thu, 28 Mar 2024 02:34:58 GMT

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 developers 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/kftraybrew 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:

https://youtu.be/nqEhmcKeCc4

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 }]

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: d

https://www.youtube.com/watch?v=BAdL7IzaEh8

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

Star us on Github

Kftray Website: https://kftray.app

]]>

kftray

Local Kubernetes Cluster with Automatic kubectl port-forward configurations using kftray

Why Keep Services Inside the Cluster?

Tools You'll Need

Cloning the Repository

Understanding the Terraform Code

Project Structure

providers.tf

variables.tf

kind.tf

locals.tf

helm.tf

templates/

outputs.tf

Applying the Terraform Configuration

Installing Kftray

Importing Port-Forward Configurations into Kftray

Using Kftray GUI

Using Kftui (Terminal Interface)

Accessing Your Services Locally

Custom Kftray Settings

Adjusting Kftray Port Forwarding Settings

Cleaning Up

Conclusion

Port Forward Transition from SPDY to WebSockets in Kubernetes 1.30

Understanding SPDY:

Why WebSockets?

Kep 4006

Implementation Overview:

API server changes:

Client (kubectl) Changes:

Websockets in kubectl port-forward with Kind

Setup Env

Install Dependencies on Mac M1

Building the kubernetes and kubectl 1.30 image

Kind Cluster Configs

Create the cluster

Deploy a sample app

Forward the Port Using WebSockets

Verifying WebSocket Port Forwarding

KEP Roadmap Port Forward over Websockets

KEP Roadmap RemoteCommand over websockets (exec, cp, attach)

Conclusion

Kubectl Port-forward Flow Explained

Sequence Diagram Explained

Initialization

Authentication & Authorization

Information Retrieval for Pod

Port-forwarding Session Establishment

Configuring iptables for Port Forwarding

SPDY Session for Port Forwarding

Conclusion

Kubernetes Debugging: How to Handle Multiple kubectl port-forward from your System Tray

The Pain of Kubernetes Debugging with Kubectl Port Forward

Introducing KFtray: A Developer Tool for Kubernetes

A Case Study: Debugging Microservices With and Without KFtray

Get Started

Installation

Configuring Your First Port Forward

Export configurations to a JSON file

Sharing the configurations through Git

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

Client (`kubectl`) Changes:

Websockets in `kubectl port-forward` with Kind