Networking on marktaguiad.dev

Cilium Network Policy: CiliumNetworkPolicy

marktaguiad@marktaguiad.dev (Mark Taguiad) — Tue, 28 Apr 2026 00:00:00 +0000

CiliumNetworkPolicy (CNP) is the most commonly used policy type in Cilium.

It is namespace-scoped, meaning the policy applies only within the namespace where it is created.

This is the policy most teams use for real-world application security because it enables zero-trust controls at Layer 3, Layer 4, and Layer 7.

If Kubernetes NetworkPolicy is a basic firewall, CiliumNetworkPolicy is the full application-aware policy engine.

What discussed and showed here is similar with CiliumClusterwideNetworkPolicy, the only difference it the policy is cluster wide. Read more on that topic and how to combine these policies.

Cilium Network Policy: Kubernetes NetworkPolicy

marktaguiad@marktaguiad.dev (Mark Taguiad) — Sun, 26 Apr 2026 00:00:00 +0000

When people first start working with Cilium policies, the easiest way to understand them is to group them into two simple ideas:

Who can talk to what?
What they’re allowed to do once connected?

That mental model maps directly to how Cilium builds policy enforcement—from basic workload isolation all the way up to application-aware HTTP filtering.

If you already think in terms of namespace rules and Layer 7 rules like HTTP GET/POST like we did in Istio, you’re already on the right track. Cilium simply expands that model into something much more powerful and much more granular.

Cilium Gateway API

marktaguiad@marktaguiad.dev (Mark Taguiad) — Sat, 25 Apr 2026 00:00:00 +0000

Cilium Gateway API support is a modern replacement for traditional Kubernetes Ingress controllers.

Instead of relying on standalone ingress proxies, Cilium integrates Gateway API directly into the networking stack using eBPF and Envoy, enabling:

HTTP / HTTPS routing
TLS passthrough
TLS termination
Traffic splitting
Header manipulation
Standards-based ingress with Kubernetes Gateway API

Cilium’s operator acts as the Gateway API controller and manages:

GatewayClass
Gateway
HTTPRoute
LoadBalancer Services
eBPF traffic routing

This is similar with Istio Gateway, for our example let’s use the same deployments/apps.

Cilium ClusterMesh: Connecting Kubernetes Clusters

marktaguiad@marktaguiad.dev (Mark Taguiad) — Fri, 24 Apr 2026 00:00:00 +0000

Cilium is a Kubernetes CNI built on eBPF, replacing the traditional iptables-heavy networking model with kernel-level packet processing. Instead of relying on large iptables chains for routing, filtering, and service load balancing, Cilium injects eBPF programs directly into the Linux kernel datapath for lower latency and better scalability.

This would require a whole book in explaining eBPF, so we will not dwell in that. Let’s focus first on connecting two Kubernetes Cluster.

Istio: Fault Injection, Retries and Circuit Breaker

marktaguiad@marktaguiad.dev (Mark Taguiad) — Sat, 28 Mar 2026 00:00:00 +0000

Continuation of Kubernetes Istio.

I’ve mentioned in this post that will sticking with HTTPRoute, but feature discussed here only support (for now) Istio API.

Ingress Gateway

Istio deploys a default resource for this, and for this example we are using the default ingress gateway ingressgateway.

If you want to create a custom ingress gateway.

istio-gateway.yaml

 1apiVersion: install.istio.io/v1alpha1
 2kind: IstioOperator
 3metadata:
 4  name: istio-control-plane
 5  namespace: istio-system
 6spec:
 7  components:
 8    ingressGateways:
 9      - name: istio-ingressgateway-prod
10        namespace: istio-system
11        enabled: true
12        label:
13          istio: ingressgateway-prod
14
15      - name: istio-ingressgateway-dev
16        namespace: istio-system
17        enabled: true
18        label:
19          istio: ingressgateway-dev

This will create two ingress gateway.

Istio: mTLS and RBAC

marktaguiad@marktaguiad.dev (Mark Taguiad) — Tue, 24 Mar 2026 00:00:00 +0000

Continuation of Kubernetes Istio, this time we’ll focus on Security.

Security

mTLS (Mutual TLS)

This will ensure that service-to-service traffic is encrypted and authenticated.

Istio allows you to configure three main modes per namespace, workload, or globally:

Mode	Behavior	When to Use
STRICT	Only allows mTLS-encrypted traffic. Plain HTTP connections are rejected.	Best for production when you want full security between services.
PERMISSIVE	Accepts both mTLS-encrypted and plain HTTP traffic.	Useful during gradual migration to mTLS. Old workloads can still communicate without encryption.
DISABLE	Does not use mTLS at all.	For testing, legacy workloads, or non-critical traffic.

You might get confused with the HTTPS traffic, it just mean that all traffic are converted by istio envoy to mTLS. So as long as the request is going through first the sidecar then it is valid.

Istio: Routing

marktaguiad@marktaguiad.dev (Mark Taguiad) — Mon, 23 Mar 2026 00:00:00 +0000

Modern applications are no longer built as single, monolithic systems—they’re composed of many small, interconnected services. Managing how these services communicate can quickly become complex, especially as systems scale. This is where Istio comes in.

Istio acts as a powerful service mesh that sits between your services and handles three critical concerns: traffic management, security, and observability.

With Istio, you gain fine-grained control over how traffic flows between services—enabling advanced deployment strategies like A/B testing and canary releases with ease. At the same time, it strengthens service-to-service security and provides deep visibility into your system through metrics, logs, and tracing.

Kubernetes Metallb

marktaguiad@marktaguiad.dev (Mark Taguiad) — Tue, 10 Mar 2026 15:08:20 +0800

In cloud environments, Kubernetes provides external load balancing easily using Service type LoadBalancer, which integrates with cloud provider load balancers.

However, in bare-metal Kubernetes clusters, there is no built-in implementation for external load balancers. As a result, creating a LoadBalancer service would remain in a pending state.

MetalLB solves this problem by providing a network load balancer implementation for bare-metal Kubernetes clusters, allowing services to expose external IP addresses just like in cloud environments.

Kubernetes Networking

marktaguiad@marktaguiad.dev (Mark Taguiad) — Thu, 05 Mar 2026 23:54:49 +0800

For applications running inside Kubernetes to function correctly, they must be able to communicate with each other and with external systems. Kubernetes provides a networking model that enables communication between Pods, Services, and external clients.

Pod Internal

Each Pod receives its own internal IP address inside the Kubernetes cluster. This allows Pods to communicate directly with each other using that IP.

Linux Networking

marktaguiad@marktaguiad.dev (Mark Taguiad) — Wed, 11 Jun 2025 00:00:00 +0000

Show network

To view your current network interface.

Networking on marktaguiad.dev

Cilium Network Policy: CiliumNetworkPolicy

Cilium Network Policy: Kubernetes NetworkPolicy

Cilium Gateway API

Cilium ClusterMesh: Connecting Kubernetes Clusters

Istio: Fault Injection, Retries and Circuit Breaker

Table of Contents

Ingress Gateway

Istio: mTLS and RBAC

Table of Contents

Security

mTLS (Mutual TLS)

Istio: Routing

Kubernetes Metallb

Kubernetes Networking

Table of Contents

Pod Internal

Linux Networking

Table of Contents

Show network