How to work with channels?

Thu, 02 Apr 2026 00:25:43 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

In this article we will understand how to work with channels.

What is a channel? Why it is needed?

Channels are used to pass data between goroutines.
They are a way to synchronize the flow of data between different parts of a program.

When to use channels?

Let's see the example below.

Have 2 goroutines to calculate the sum of an array.

First, we will calculate the sum of the first half of the array.

Second, we will calculate the sum of the second half of the array.

package main

import (
    "fmt"
)

func add(a []int, c chan int) {
    sum := 0
    for _, v := range a {
        sum += v
    }
    c <- sum
}

func main() {
    a := []int{7, 2, 8, -9, 4, 0}

    c1 := make(chan int)
    go add(a[:len(a)/2], c1)

    c2 := make(chan int)
    go add(a[len(a)/2:], c2)

    x, y := <-c1, <-c2
    fmt.Println(x, y, x+y)
}

Finally, we will print the sum of the first half and the second half of the array.

Output:

gk@jarvis:~/exp/code/rd/go-exmaple$ go run main.go 
17 -5 12

Conclusion

Channels play a crucial role in concurrent programming by enabling safe communication and synchronization between goroutines.
This makes it easier to build concurrent programs that are both efficient and safe.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Resolving Kubernetes Ingress Issues: Limitations and Gateway Insights

Fri, 13 Feb 2026 03:54:50 +0000

Introduction

Ingresses have been, since the early versions of Kubernetes, the most common way to expose applications to the outside. Although their initial design was simple and elegant, the success of Kubernetes and the growing complexity of use cases have turned Ingress into a problematic piece: limited, inconsistent between vendors, and difficult to govern in enterprise environments.

In this article, we analyze why Ingresses have become a constant source of friction, how different Ingress Controllers have influenced this situation, and why more and more organizations are considering alternatives like Gateway API.

What Ingresses are and why they were designed this way

The Ingress ecosystem revolves around two main resources:

IngressClass

Defines which controller will manage the associated Ingresses. Its scope is cluster-wide, so it is usually managed by the platform team.

Ingress

It is the resource that developers use to expose a service. It allows defining routes, domains, TLS certificates, and little more.

Its specification is minimal by design, which allowed for rapid adoption, but also laid the foundation for current problems.

The problem: a standard too simple for complex needs

As Kubernetes became an enterprise standard, users wanted to replicate advanced configurations of traditional proxies: rewrites, timeouts, custom headers, CORS, etc.
But Ingress did not provide native support for all this.

Vendors reacted… and chaos was born.

Annotations vs CRDs: two incompatible paths

Different Ingress Controllers have taken very different paths to add advanced capabilities:

Annotations (NGINX, HAProxy…)

Advantages:

Flexible and easy to use
Directly in the Ingress resource

Disadvantages:

Hundreds of proprietary annotations
Fragmented documentation
Non-portable configurations between vendors

Custom CRDs (Traefik, Kong…)

Advantages:

More structured and powerful
Better validation and control

Disadvantages:

Adds new non-standard objects
Requires installation and management
Less interoperability

Result?
Infrastructures deeply coupled to a vendor, complicating migrations, audits, and automation.

The complexity for development teams

The design of Ingress implies two very different responsibilities:

Platform: defines IngressClass
Application: defines Ingress

But the reality is that the developer ends up making decisions that should be the responsibility of the platform area:

Certificates
Security policies
Rewrite rules
CORS
Timeouts
Corporate naming practices

This causes:

Inconsistent configurations
Bottlenecks in reviews
Constant dependency between teams
Lack of effective standardization

In large companies, where security and governance are critical, this is especially problematic.

NGINX Ingress: the decommissioning that reignited the debate

The recent decommissioning of the NGINX Ingress Controller has highlighted the fragility of the ecosystem:

Thousands of clusters depend on it
Multiple projects use its annotations
Migrating involves rewriting entire configurations

This has reignited the conversation about the need for a real standard… and there appears Gateway API.

Gateway API: a promising alternative (but not perfect)

Gateway API was born to solve many of the limitations of Ingress:

Clear separation of responsibilities (infrastructure vs application)
Standardized extensibility
More types of routes (HTTPRoute, TCPRoute…)
Greater expressiveness without relying on proprietary annotations

But it also brings challenges:

Requires gradual adoption
Not all vendors implement the same
Migration is not trivial

Even so, it is shaping up to be the future of traffic management in Kubernetes.

Conclusion

Ingresses have been fundamental to the success of Kubernetes, but their own simplicity has led them to become a bottleneck. The lack of interoperability, differences between vendors, and complex governance in enterprise environments make it clear that it is time to adopt more mature models.

Gateway API is not perfect, but it moves in the right direction.
Organizations that want future stability should start planning their transition.

Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Coder Legion - Recent posts tagged between

How to work with channels?

What is a channel? Why it is needed?

When to use channels?

Conclusion

Resolving Kubernetes Ingress Issues: Limitations and Gateway Insights

Introduction

What Ingresses are and why they were designed this way

IngressClass

Ingress

The problem: a standard too simple for complex needs

Annotations vs CRDs: two incompatible paths

Annotations (NGINX, HAProxy…)

Custom CRDs (Traefik, Kong…)

The complexity for development teams

NGINX Ingress: the decommissioning that reignited the debate

Gateway API: a promising alternative (but not perfect)

Conclusion