Kubernetes 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.

Kubernetes Sealed Secrets

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

k8s-sealed-secrets.png Managing secrets in Kubernetes is a bit tricky. Native Secret objects are only base64-encoded—not encrypted—making them unsafe for Git-based workflows. If you’re doing GitOps (e.g., with Argo CD), committing raw secrets is not an option.

This is where Sealed Secrets comes in.

Why Sealed Secret?

Sealed Secrets uses asymmetric encryption to solve one problem:

Kubernetes Autoscaling

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

In Kubernetes, scaling is how you adjust your application to handle more or less traffic. There are two main types: horizontal scaling and vertical scaling.

Horizontal Scaling vs Vertical Scaling

Feature	Horizontal Scaling	Vertical Scaling
Method	Add/remove pods	Increase/decrease resources
Tool	HPA	VPA
Best for	Stateless apps	Stateful or legacy apps
Downtime	None	Possible restart
Limit	Cluster size	Node capacity

Horizontal Scaling

This uses the Horizontal Pod Autoscaler to scale number of pods automatically.

Kubernetes Multi-Tenancy

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

Multi-tenancy in Kubernetes is the practice of running multiple users, teams, or customers (tenants) on a shared cluster while keeping them isolated, secure, and fairly resourced.

At first glance, it sounds simple—just create namespaces and you’re done. In reality, building a safe multi-tenant platform requires layering multiple controls together.

Overview

Let’s assign team web-dev to namespace web.

Create GKE Cluster with Terraform/Opentofu 0x03

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

Part 3 of this post

To make this really modular let’s create environemnt for Dev and Prod.

Let’s assign standard gke to dev and autopilot gke to prod.

This approach keeps our infrastructure:

consistent
reusable
environment-aware
easy to scale

Providers

This is present in both environment.

provider.tf

 1terraform {
 2  required_providers {
 3    google = {
 4      source  = "hashicorp/google"
 5      version = "7.26.0"
 6    }
 7    kubernetes = {
 8      source  = "hashicorp/kubernetes"
 9      version = "~> 2.0"
10    }
11
12    helm = {
13      source  = "hashicorp/helm"
14      version = "~> 2.10" # or latest
15    }
16  }
17}
18
19provider "google" {
20  credentials = file(var.credentials_file)
21  project = var.project_id
22  region  = var.region
23}
24
25data "google_client_config" "default" {}
26
27provider "kubernetes" {
28  host  = "https://${module.gke.endpoint}"
29  token = data.google_client_config.default.access_token
30
31  cluster_ca_certificate = base64decode(
32    module.gke.ca_certificate
33  )
34}
35
36provider "helm" {
37  kubernetes {
38    host  = "https://${module.gke.endpoint}"
39
40    token = data.google_client_config.default.access_token
41
42    cluster_ca_certificate = base64decode(
43      module.gke.ca_certificate
44    )
45  }
46}

Development Environment

The dev environment is designed for flexibility and cost efficiency.

Create GKE Cluster with Terraform/Opentofu 0x02

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

Part 2 of this post

GKE Module

This module is where everything comes together—network, IAM, and node pools—to create a working GKE cluster.

Standard vs Autopilot

Feature	Standard	Autopilot
Node control	Full	None
Scaling	Manual + autoscaler	Fully managed
Operations	You manage	Google manages
Flexibility	High	Limited

Standard

Gives you full control over nodes and scaling.

Create GKE Cluster with Terraform/Opentofu 0x01

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

Still a not-so comprehensive guide to create GKE Cluster with Terraform/Opentofu.

Visit the previous post before proceeding with this one.

Repo for this post: g-ulap-demo.

Overview

This topic is quite big and not a single blog or post would answer all your question. I advice you to read on documentations and blog posts. This post would be too long if I explain every details.

Kubernetes RBAC

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

Role‑Based Access Control (RBAC) is a core part of Kubernetes security — it lets you grant precise permissions to users, groups, or service accounts so they can do only what they’re allowed. In this hands‑on guide, we’ll go step‑by‑step through:

creating a Kubernetes user
assigning permissions using RBAC
testing permissions

Create Kubernetes User

Let’s automate this process-in the perspective of an admin. Use the script to create user.

Istio: A/B Testing and Canary Deployment

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

A/B testing and Canary Deployment allows you to route traffic between different versions of your application to compare performance, behavior, or user experience.

With Istio, you can control traffic without changing application code—just by configuring the service mesh.

Replicate this using this repo.

1kubectl apply -k kube/ab-testing/demo

A/B Testing vs Canary Deployment

Aspect	Canary Deployment	A/B Testing
Purpose	Safe rollout	Experimentation
Traffic split	Gradual (10% → 100%)	Fixed (often 50/50)
Decision basis	Errors, latency	User behavior, metrics
End goal	Replace old version	Pick best variant
Versions	Usually same feature	Different UX/features

A/B Testing

Labels

Label your deployments properly.

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 Monitoring & Logging

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

If you have used prometheus in your docker or podman environment then this is much easier to setup. Unlike in your docker/podman where you have to create the config and scrape config from scratch, in k8s some good helm repo are already available to use and do all that for you. Also Prometheus in Kubernetes has a dynamic service discovery, so any resources added to the cluster will autotmatically added and monitored.

Kubernetes KubeVirt

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

Info

Don’t have any use case for this yet, all of my running services is in microservice/container. Will update post if I have more time to explore this, or maybe if used in work which I don’t have currently - HIRE ME PO!

Kubernetes is designed to run containerized workloads, but many real-world systems still rely on virtual machines (VMs).

KubeVirt extends Kubernetes by allowing you to run and manage Virtual Machines alongside containers using the same Kubernetes API.

Kubernetes Jobs, CronJob and Init Container

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

In Kubernetes, some workloads need to run continuously, such as web servers or APIs. These are typically managed by controllers like Deployments.

However, other workloads only need to run once and finish, such as scripts, data processing tasks, or backups. Kubernetes provides Jobs and CronJobs to handle these types of workloads.

Job

A Job is a Kubernetes resource used to run a task until completion.

Kubernetes Daemonsets

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

Kubernetes has multiple controllers to manage workloads. So far, we’ve learned about Deployments and StatefulSets, which help run Pods that scale and keep state. However, some workloads must run on every node in a cluster — this is where DaemonSets come in.

Why Daemonsets?

Most Kubernetes workloads (like Deployments) allow Pods to run anywhere in the cluster. But some software needs to be present on every node — regardless of what Pods are running there.

Kubernetes Statefulsets

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

Kubernetes has several controllers to manage workloads. While Deployments are ideal for stateless applications, many real‑world use cases require stateful behavior — applications that store data, maintain identity, and rely on stable storage.

This is where StatefulSets come in. They provide stable identity, stable storage, and ordered deployment for stateful applications.

Why StatefulSets?

Stateless apps don’t care which instance serves a request. But stateful workloads often require:

Kubernetes Deployments

marktaguiad@marktaguiad.dev (Mark Taguiad) — Fri, 06 Mar 2026 23:07:51 +0800

In Kubernetes, ReplicaSets ensure that a specific number of Pods are always running. However, most real applications need to be updated frequently. This is where Deployments come in.

A Deployment is a higher-level Kubernetes resource that manages ReplicaSets and allows applications to be updated, scaled, and rolled back safely.

Why Deployment?

ReplicaSets ensure that the correct number of Pods are running, but they do not provide advanced update mechanisms.

Kubernetes Controller

marktaguiad@marktaguiad.dev (Mark Taguiad) — Fri, 06 Mar 2026 12:15:40 +0800

Kubernetes is designed to keep applications running even when failures occur. One of the key mechanisms that enables this is the Controller.

Controllers continuously monitor the cluster and ensure that the actual state matches the desired state. If something goes wrong, Kubernetes automatically corrects it.

This behavior is commonly referred to as self-healing.

It performs three main tasks:

Observe the current state
Compare it with the desired state
Take action if they differ

This loop runs continuously inside the Kubernetes control plane.

Kubernetes Volume

marktaguiad@marktaguiad.dev (Mark Taguiad) — Fri, 06 Mar 2026 03:32:32 +0800

Containers in Kubernetes are ephemeral by default. This means that when a container stops or a Pod is deleted, any data stored inside the container filesystem is lost.

To solve this problem, Kubernetes provides Volumes, which allow data to persist and be shared between containers in a Pod.

Volumes are mounted into containers and provide persistent or shared storage depending on the type used.

How Volume Works

Remember the first example we make, this time we will mount with different type of Kubernetes Volumes.

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.

Kubernetes Pod

marktaguiad@marktaguiad.dev (Mark Taguiad) — Thu, 05 Mar 2026 17:22:20 +0800

In Kubernetes, you do not deploy containers directly. Instead, containers run inside a Pod, which acts as a wrapper around one or more containers. Pods are the smallest deployable unit in the Kubernetes.

A Pod provides:

Shared specification for containers
Shared storage (volumes)
Shared network

Kubeconfig

Before we deploy pods, let’s first discuss kubeconfig for cluster access. Check this link for further explanation.

Kubernetes Architecture

marktaguiad@marktaguiad.dev (Mark Taguiad) — Thu, 05 Mar 2026 07:22:20 +0800

Kubernetes (K8s) is an open-source platform used to automate the deployment, scaling, and management of containerized applications. It is designed to simplify running large numbers of containers in production environments.

Container Management Problem

Modern applications often consist of multiple services built with different technologies.

Example architecture:

Frontend → Node.js
Databases → MySQL
Backend service - Java

All of these services may run as containers.

Kubernetes on marktaguiad.dev

Cilium Network Policy: CiliumNetworkPolicy

Cilium Network Policy: Kubernetes NetworkPolicy

Cilium Gateway API

Cilium ClusterMesh: Connecting Kubernetes Clusters

Kubernetes Sealed Secrets

Table of Contents

Why Sealed Secret?

Kubernetes Autoscaling

Table of Contents

Horizontal Scaling vs Vertical Scaling

Horizontal Scaling

Kubernetes Multi-Tenancy

Table of Contents

Overview

Create GKE Cluster with Terraform/Opentofu 0x03

Table of Contents

Providers

Development Environment

Create GKE Cluster with Terraform/Opentofu 0x02

Table of Contents

GKE Module

Standard vs Autopilot

Standard

Create GKE Cluster with Terraform/Opentofu 0x01

Table of Contents

Overview

Kubernetes RBAC

Table of Contents

Create Kubernetes User

Istio: A/B Testing and Canary Deployment

Table of Contents

A/B Testing vs Canary Deployment

A/B Testing

Labels

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 Monitoring & Logging

Kubernetes KubeVirt

Kubernetes Jobs, CronJob and Init Container

Table of Contents

Job

Kubernetes Daemonsets

Table of Contents

Why Daemonsets?

Kubernetes Statefulsets

Table of Contents

Why StatefulSets?

Kubernetes Deployments

Table of Contents

Why Deployment?

Kubernetes Controller

Kubernetes Volume

Table of Contents

How Volume Works

Kubernetes Networking

Table of Contents

Pod Internal

Kubernetes Pod

Table of Contents

Kubeconfig

Kubernetes Architecture

Table of Contents

Container Management Problem