DEV Community: Kadir Belkuyu

The Kubernetes Context Switching Nightmare is Over

Kadir Belkuyu — Tue, 09 Dec 2025 19:42:10 +0000

If you work with multiple Kubernetes clusters daily, you know the pain. Production, staging, development, that random test cluster someone spun up last month — they all live in your kubeconfig file, and switching between them feels like navigating a maze blindfolded.

I got tired of it. So I built kubecfg.

What is kubecfg?

kubecfg is a CLI tool that simplifies kubeconfig management. It lets you:

Add new cluster configs with custom names
List all your contexts at a glance
Switch contexts with optional namespace selection
Manage namespaces interactively
Rename contexts to something memorable
Remove contexts you no longer need
Merge multiple kubeconfig files

The killer feature? Interactive pickers with fuzzy selection. No more copy-pasting long context names.

Quick Demo

Switching Context with Namespace

kubecfg use -n

That's it. One command. It shows you an interactive context picker, then asks which namespace you want. Both selections happen in one flow.

Select context
  minikube
▸ production-eks
  staging-gke
  dev-local

✓ production-eks

Select namespace
  default
  kube-system
▸ backend-services
  frontend
  monitoring

✓ backend-services

Switched to context 'production-eks' with namespace 'backend-services'

Or if you just want to switch context without the namespace prompt:

kubecfg use production-eks

Need a specific namespace directly?

kubecfg use production-eks -n backend-services

The -n flag is smart. Use it without a value for interactive selection, or pass a namespace directly.

Installation

Homebrew (macOS)

brew tap kadirbelkuyu/tap
brew install kadirbelkuyu/tap/kubecfg

Go Install

go install github.com/kadirbelkuyu/kubecfg@latest

From Source

git clone https://github.com/kadirbelkuyu/kubecfg.git
cd kubecfg
go build -o kubecfg .
sudo mv kubecfg /usr/local/bin/

Commands in Detail

Adding a New Cluster

When you download a kubeconfig from AWS EKS, GCP GKE, or Azure AKS, the context names are usually terrible. Something like arn:aws:eks:us-east-1:123456789:cluster/my-cluster.

With kubecfg, you can import it with a sensible name:

kubecfg add ~/Downloads/eks-config.yaml --name production-eks

The original file stays untouched. The context gets added to your main kubeconfig with the name you chose.

Listing All Contexts

kubecfg list

Output:

CURRENT  NAME            CLUSTER         SERVER                              NAMESPACE
*        production-eks  production-eks  https://xxx.eks.amazonaws.com       backend
         staging-gke     staging-gke     https://xxx.gke.googleapis.com      -
         dev-local       minikube        https://192.168.49.2:8443           default

Clean, tabular output. The asterisk shows your current context. Namespace shows what's configured, or - if using default.

Interactive Context Switching

kubecfg use

No arguments needed. An interactive picker appears. Use arrow keys to navigate, Enter to select.

Select context
  minikube
▸ production-eks
  staging-gke

✓ production-eks

Switched to context 'production-eks'

Namespace Management

Switch namespace for your current context:

kubecfg ns

Interactive picker pulls namespaces directly from the cluster:

Select namespace
  default
  kube-system
▸ backend-services
  monitoring

✓ backend-services

Namespace set to 'backend-services'

Or set it directly:

kubecfg ns kube-system

Check current namespace:

kubecfg ns current
# Output: backend-services

Renaming Contexts

That auto-generated context name bugging you?

kubecfg rename arn:aws:eks:us-east-1:123456789:cluster/prod production

Clean and simple.

Removing Contexts

kubecfg remove old-cluster

You'll get a confirmation prompt:

Remove context 'old-cluster'? [y/N]:

Skip the prompt with --force:

kubecfg remove old-cluster --force

Merging Configs

Got kubeconfig files scattered everywhere?

kubecfg merge config1.yaml config2.yaml config3.yaml -o merged.yaml

All contexts, clusters, and users get combined into one file. Duplicates are handled gracefully.

Architecture Deep Dive

I built kubecfg with Clean Architecture principles. Not because it's trendy, but because I wanted the codebase to be maintainable and testable.

kubecfg/
├── cmd/                    # CLI commands (Cobra)
│   ├── root.go
│   ├── add.go
│   ├── list.go
│   ├── use.go
│   ├── ns.go
│   ├── remove.go
│   ├── rename.go
│   └── merge.go
├── internal/
│   ├── domain/             # Core business entities
│   │   ├── kubeconfig.go
│   │   ├── repository.go
│   │   └── errors.go
│   ├── application/        # Business logic
│   │   └── service.go
│   └── infrastructure/     # External implementations
│       ├── file_repository.go
│       └── kubernetes_client.go
└── main.go

Domain Layer

Pure Go structs representing kubeconfig structure:

type KubeConfig struct {
    APIVersion     string
    Kind           string
    CurrentContext string
    Clusters       []ClusterEntry
    Contexts       []ContextEntry
    Users          []UserEntry
}

No dependencies on external packages. Just the core data model.

Application Layer

Business logic lives here. The Service struct handles all operations:

type Service struct {
    repo domain.Repository
}

func (s *Service) UseContext(path, contextName, namespace string) error {
    config, err := s.repo.Load(path)
    if err != nil {
        return err
    }

    _, idx := config.FindContext(contextName)
    if idx < 0 {
        return domain.ErrContextNotFound
    }

    config.CurrentContext = contextName

    if namespace != "" {
        config.Contexts[idx].Context.Namespace = namespace
    }

    return s.repo.Save(path, config)
}

The service doesn't know how configs are stored or loaded. It works with the repository interface.

Infrastructure Layer

Concrete implementations for file I/O and Kubernetes API calls:

type FileRepository struct{}

func (r *FileRepository) Load(path string) (*domain.KubeConfig, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return nil, err
    }

    var config domain.KubeConfig
    if err := yaml.Unmarshal(data, &config); err != nil {
        return nil, domain.ErrInvalidConfig
    }

    return &config, nil
}

The Kubernetes client fetches namespaces directly from the cluster for the interactive picker:

type KubernetesClient struct {
    kubeconfigPath string
}

func (k *KubernetesClient) ListNamespaces() ([]string, error) {
    config, err := clientcmd.BuildConfigFromFlags("", k.kubeconfigPath)
    if err != nil {
        return nil, err
    }

    clientset, err := kubernetes.NewForConfig(config)
    if err != nil {
        return nil, err
    }

    namespaceList, err := clientset.CoreV1().Namespaces().List(
        context.Background(), 
        metav1.ListOptions{},
    )
    if err != nil {
        return nil, err
    }

    namespaces := make([]string, len(namespaceList.Items))
    for i, ns := range namespaceList.Items {
        namespaces[i] = ns.Name
    }

    return namespaces, nil
}

The Smart Namespace Flag

One feature I'm particularly proud of is the -n flag behavior on the use command.

The challenge: How do you make a single flag that can:

Do nothing (just switch context)
Trigger interactive selection
Accept a direct value

Cobra's NoOptDefVal made this possible:

func init() {
    useCmd.Flags().StringVarP(&namespaceFlag, "namespace", "n", "", 
        "set namespace (use -n without value for interactive selection)")
    useCmd.Flags().Lookup("namespace").NoOptDefVal = "__interactive__"
}

Now the flag works three ways:

Command	Behavior
`kubecfg use prod`	Switch context only
`kubecfg use prod -n`	Switch context + interactive namespace
`kubecfg use prod -n backend`	Switch context + set namespace

The resolution logic is clean:

func resolveNamespace(cmd *cobra.Command, contextName string) string {
    if !cmd.Flags().Changed("namespace") {
        return ""
    }

    if namespaceFlag == "__interactive__" {
        return selectNamespaceForContext(contextName)
    }

    return namespaceFlag
}

Error Handling

I defined domain-specific errors that are meaningful to users:

var (
    ErrConfigNotFound   = errors.New("kubeconfig file not found")
    ErrContextNotFound  = errors.New("context not found")
    ErrContextExists    = errors.New("context already exists")
    ErrInvalidConfig    = errors.New("invalid kubeconfig format")
    ErrNoCurrentContext = errors.New("no current context set")
)

When something goes wrong, you get a clear message instead of a stack trace.

Backup System

Before any modification, kubecfg creates a timestamped backup:

~/.kube/config.backup.20241208-143022

Accidentally removed the wrong context? Your backup is right there.

Tech Stack

Go 1.24 - Fast compilation, single binary output
Cobra - Industry standard CLI framework
promptui - Beautiful interactive prompts
client-go - Official Kubernetes client library
yaml.v3 - YAML parsing with proper type handling

Why I Built This

I've been working with Kubernetes for years. The tooling around kubeconfig management always felt like an afterthought. You either use kubectl's verbose commands or install multiple tools for context and namespace management.

I wanted:

One tool that handles both context and namespace
Interactive pickers that actually pull from the cluster
Clean output that's easy to read
Safe operations with backups and confirmations
Extensible codebase that I can maintain

kubecfg is the result. It's the tool I wish I had when I started working with multiple clusters.

What's Next

A few things on my roadmap:

Shell completions - Bash, Zsh, Fish
Config validation - Detect broken references
Context groups - Organize contexts by environment
Export command - Extract a single context to a file

Try It Out

go install github.com/kadirbelkuyu/kubecfg@latest
kubecfg use -n

The code is open source. Star the repo if you find it useful, and feel free to open issues or PRs.

GitHub: github.com/kadirbelkuyu/kubecfg

Final Thoughts

Building developer tools is satisfying in a way that application development sometimes isn’t. You’re solving real problems you face daily. Every feature comes from actual pain points.

If you manage multiple Kubernetes clusters, give kubecfg a try. And if you've built similar tools to scratch your own itch, I'd love to hear about them

Follow me for more Kubernetes and Go content. If you found this useful, a clap or share helps others discover the tool.

Conventional Commits

Kadir Belkuyu — Sun, 16 Nov 2025 12:20:18 +0000

Conventional Commits Rehberi

Bu rehber, https://www.conventionalcommits.org/en/v1.0.0/ adresi referans alınarak hazırlanmıştır.

Temel Yapı

Her commit mesajı şu formata uygun olmalıdır:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Bileşenler

type: Yaptığınız değişikliğin türünü belirtir.
scope (opsiyonel): Değişikliğin hangi bölümünü etkilediğini belirtir.
description: Değişikliğin kısa ve öz açıklaması.
body (opsiyonel): Daha detaylı açıklama yapılabilir.
footer (opsiyonel): Ek bilgiler veya referanslar içerir.

Type (Tür)

Kullanabileceğiniz commit türleri şöyledir:

Type	Açıklama
feat	Yeni bir özellik eklendi
fix	Bir hata düzeltildi
docs	Dokümantasyon güncellendi
style	Kod formatı veya stil değişiklikleri (işlevsel olmayan)
refactor	Kod yeniden düzenlendi, işlev değişmedi
test	Testler eklendi veya güncellendi
chore	Yapılandırma/bakım gibi diğer değişiklikler

Scope (Opsiyonel)

Scope, değişikliğin hangi alanı etkilediğini belirtir. Örnekler:

feat(login)
fix(database)
docs(readme)
style(css)

Scope tamamen isteğe bağlıdır ancak büyük projelerde anlaşılabilirlik sağlar.

Description

Description, commit mesajının en kritik kısmıdır.
Kısa, öz ve eylem odaklı olmalıdır.

Örnek:

feat(auth): kullanıcı girişi özelliği eklendi

Body (Opsiyonel)

Body kısmı, değişiklik hakkında daha fazla detay vermek için kullanılır.

Örnek:

feat(api): ürün listeleme endpointi güncellendi

Yeni filtreleme parametreleri eklendi:
- category
- price_range

Footer (Opsiyonel)

Footer genellikle şu amaçlarla kullanılır:

1. Breaking Changes

Önceki sürümlerle uyumsuz değişiklikler:

BREAKING CHANGE: auth token yapısı tamamen yenilendi

2. Issue Referansları

Closes #123

Örnek Commit Mesajları

feat(login): kullanıcı adı ve şifre ile giriş imkanı eklendi

fix(database): veritabanı bağlantı hatası düzeltildi

docs(readme): kurulum talimatları eklendi

style(css): stiller yeniden düzenlendi

refactor(api): kod daha modüler hale getirildi

test(unit): yeni birim testleri eklendi

chore(deps): bağımlılıklar güncellendi

Silme ve Ekleme İşlemleri

Silme veya ekleme işlemleri yine type üzerinden ifade edilir.

Ekleme:

  feat(feature): yeni özellik eklendi

Silme/fix:

  fix(bug): hatalı kod kaldırıldı

Commit Mesajlarının İngilizce Olması

Mesajlar Türkçe olabilir ancak uluslararası projelerde İngilizce kullanılmalıdır.
Bu standart, ekipler ve open-source projelerde iletişimi kolaylaştırır.

Daha Fazla Bilgi

Detaylı dokümantasyon için:
https://www.conventionalcommits.org/en/v1.0.0/

A Beginner’s Journey into Ansible: The Ultimate Guide

Kadir Belkuyu — Mon, 20 Mar 2023 05:11:27 +0000

Embark on your path to mastering IT automation with Ansible’s versatile and user-friendly capabilities

Introduction
Ansible has emerged as a leading open-source solution for IT automation, allowing users to efficiently manage and configure their infrastructure. By simplifying repetitive tasks, streamlining configuration updates, and facilitating application deployment, Ansible has become an indispensable tool for many. In this comprehensive guide, we’ll explore the foundations of Ansible, delve into its critical components, and demonstrate how to craft a basic playbook to automate tasks on your servers.

Table of Contents

Ansible: An Overview
Installing Ansible
Organizing Hosts with Inventory Files
Mastering Ad-Hoc Commands
Playbooks, Roles, and Their Significance
Crafting Your First Playbook
Best Practices for Success
Final Thoughts

1. Ansible: An Overview
As a powerful automation platform, Ansible simplifies complex tasks and enhances server and application management. Some of its key advantages include:

No agent requirements
Human-readable YAML playbooks
A vast array of modules
Compatibility with tools like Docker, Kubernetes, and Terraform
Customizability via modules and plugins

2. Installing Ansible
To set up Ansible on your control machine (typically your local computer), follow the instructions below:
For Ubuntu/Debian:

$ sudo apt update $ sudo apt install ansible

For CentOS/RHEL:

$ sudo yum install epel-release $ sudo yum install ansible

For macOS:

$ brew install ansible

3. Organizing Hosts with Inventory Files
To define the hosts you’ll manage, Ansible employs inventory files. Create a file named inventory.ini and list your hosts in the format shown below:

[webservers]
web1.example.com
web2.example.com

[dbservers]
db1.example.com

4. Mastering Ad-Hoc Commands
Ad-hoc commands enable you to complete swift tasks on your hosts without the need for a playbook. For instance, to check the uptime of all web servers, execute:

$ ansible web_servers -i inventory.ini -m command -a "uptime" -u <username>

5. Playbooks, Roles, and Their Significance
Playbooks are the heart of Ansible. These YAML files detail the tasks and configurations to apply to your hosts. Roles, on the other hand, are sets of tasks and variables that can be reused throughout multiple playbooks.

6. Crafting Your First Playbook
Create a file named update_packages.yml and insert the following content:

---
- name: Update packages on all servers
  hosts: all
  become: yes
  tasks:
    - name: Update package list
      ansible.builtin.apt:
        update_cache: yes

    - name: Upgrade packages
      ansible.builtin.apt:
        upgrade: safe

To execute the playbook, use this command:

$ ansible-playbook -i inventory.ini update_packages.yml -u <username>

7. Best Practices for Success

Maintain modular and reusable playbooks
Leverage roles to structure your tasks
Secure sensitive data with Ansible Vault
Utilize Git for version control and collaboration
Employ CI/CD pipelines for automated testing and deployment

8. Final Thoughts
Ansible’s powerful capabilities have made it a go-to tool for IT infrastructure management. By following

Dockerize edilmiş PostgreSQL veritabanını yedekleme

Kadir Belkuyu — Thu, 17 Nov 2022 08:22:42 +0000

PostgreSQL
Bir PostgreSQL veritabanını yedeklemek ve geri yüklemek, herhangi bir sistem yöneticisi için önemli bir görevdir. Bu görevi kolaylaştıran psql yardımcı programları pg_dump ve pg_restore sayesinde bu işlem çok kısa bir sürede hallolabiliyor.

Bu yardımcı programları kullanarak sistem yöneticileri, yerel olarak veya uzaktan sürekli bir yedekleme oluşturabilir.

PostgreSQL, yaygın olarak kullanılan ilişkisel bir veritabanı sistemidir. Açık kaynaklıdır ve görevleri hızlı bir şekilde gerçekleştirmek için çok çeşitli araçlar sunar.

pg_dump
pg_dumpbir PostgreSQL veritabanını komutudur. Veritabanını bir komut dosyasına veya başka bir arşiv dosyasına çıkarır. Bu yardımcı program veritabanlarını yedeklemek içindir. Yardımcı program, veritabanı aynı anda kullanılıyor olsa bile tutarlı yedeklemeler yapar. Okuyucular, yazarlar ve diğer kullanıcılar veritabanını kullanırken engellenmeyecektir pg_dump.

pg_restore
pg_restore — pg_dump tarafından oluşturulan bir arşiv dosyasından bir PostgreSQL veritabanını geri yüklemeye yarayan psql yardımcı programıdır. İki kodunda detaylı kullanımı aşağıdaki kodlarda gösterilmiştir.

NOT: Aşağıdaki kodlar docker container ile yedekleme işlemi için değildir.

pg_dump [connection-option…] [option…] [dbname]

pg_dump örnekleri:

# testdb veritabanını sql biçiminde kaydetmek
pg_dump testdb > db.sql

# testdb veri tabanını tar biçiminde yedeklemek
pg_dump -U postgres -F c testdb > testdb.tar

# testdb veri tabanını bir dizin biçiminde yedeklemek
pg_dump -U postgres -F d testdb > db1_backup

pg_restore örnekleri

pg_restore -U postgres -Ft -d db < db.tar

pg_dumpall örnekleri:

# dumpall tüm veritabanını yedekliyecektir.
pg_dumpall -f dump_`date +%d-%m-%Y"_"%H_%M_%S`.sql

#dump_date kullanımında cihazın tarih ve saat bilgilerini alarak dosya ismi olarak atar bu sayede karışıklılık olmadan yedekleme işlemini gerçekleştirebilirsiniz

PostgreSQL veritabanını Docker tarafında yedeğini almanın bir çok yolu vardır. Bu yazıda en az uğraştırıcı olan ve ilerde otomatik bir şekilde günlük yedek almak istersenin kullanabileceğiz kodları paylaşacağım. Otomatik günlük veritabanı yedeği içinde bir çok yol bulunmaktadır. Yine en basit yöntem olarak yazacağınız script için cron job oluşturabilirsiniz. Bu yazıda Backup almak için bir bash dosyasıda kullanacağız.

Docker ile psql yedeği alma ve yedeği yükleme:

# pg_dumpall (yedeği alma)
# container name postgreSQL container ismidir. container ismini öğrenmek için:
# docker images komutunu kullanabilirsiniz.
docker exec -t container_Name pg_dumpall -c -U postgres > dump_`date +%d-%m-%Y"_"%H_%M_%S`.sql

# pg_restore (veri tabanı yedeği yükleme)
cat dump.sql | docker exec -i container_Name psql -U postgres

Restore işlemi CLI tarafında yazdığımız kodlardan biraz farklı bununsebebi Docker.

Bash dosyası:

#! /usr/bin/env bash
CONTAINER_NAME=PostgreSQLContainerName
# pg_dumpall için database ismi gerekmiyor 
DATABASE_NAME=Your_db

if [ -z $CONTAINER_NAME ]
then
echo "Usage: $0 [container name] [database name]"
exit 1
fi

if [ -z $DATABASE_NAME ]
then
echo "Usage: $0 [container name] [database name]"
exit 1
fi

set -e
set -o pipefail

# backups yedek klasörünü oluşturma 
mkdir -p "./backups"

cd backups

# PostgreSQL veri tabanı yedeği oluşturma 
# bu satırda pg_dump kullanıp istediğiniz veri tabanın yedekleyebilirsiniz
docker exec -t "$CONTAINER_NAME" pg_dumpall -c -U postgres > dump_`date +%d-%m-%Y"_"%H_%M_%S`.sql

echo ""
echo "Exporting file from container..."
echo "Done!"