githubEdit

Cloud Platforms

This guide provides specific instructions for deploying Mermin on major cloud Kubernetes platforms: Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), and Azure Kubernetes Service (AKS).

Google Kubernetes Engine (GKE)

Prerequisites

  • gcloud CLI installed and configured

  • GKE cluster created (Standard or Autopilot)

  • kubectl configured for your GKE cluster

GKE Standard Clusters

GKE Standard clusters work seamlessly with Mermin using the standard Helm deployment.

Create a GKE Standard cluster:

gcloud container clusters create mermin-cluster \
  --zone us-central1-a \
  --num-nodes 3 \
  --machine-type n1-standard-2 \
  --enable-ip-alias \
  --network "default" \
  --subnetwork "default"

# Configure kubectl
gcloud container clusters get-credentials mermin-cluster --zone us-central1-a

Deploy Mermin:

GKE Autopilot Clusters

GKE Autopilot has stricter security policies. Mermin requires some adjustments:

circle-exclamation

Create a GKE Autopilot cluster:

Deploy with Autopilot-compatible values:

GKE-Specific Configuration

Network interfaces on GKE nodes typically include:

Workload Identity (optional, for managed identity):

Set up Workload Identity:

GKE with Dataplane V2 (Cilium)

GKE Dataplane V2 uses Cilium for advanced networking features.

circle-check

How it works:

  • Kernel >= 6.6: Uses TCX (Traffic Control eXpress) with tcx_order = "first" (runs before other programs)

  • Kernel < 6.6: Uses netlink with tc_priority = 1 (runs first in chain)

Observability characteristics:

Mermin runs first in the TC chain (default behavior), meaning:

  • ✅ All traffic flows are captured

  • ✅ State continuity: Flow statistics persist across mermin restarts via map pinning

  • ✅ No flow gaps: Existing pods generate flows immediately after mermin restart

  • ℹ️ First-execution prevents orphan program issues on restart

This provides accurate flow visibility for monitoring and troubleshooting while maintaining cluster stability. Mermin operates passively (TC_ACT_UNSPEC) so running first doesn't interfere with Cilium's networking.

Verification:

After deployment, verify TC attachment and map pinning:

circle-info

Priority Tuning: If you experience CNI conflicts (rare), adjust execution order:

For TCX mode (kernel >= 6.6):

For Netlink mode (kernel < 6.6):

Note: The default first-execution strategy (tcx_order = "first", tc_priority = 1):

  • Ensures immediate flow visibility after restart (prevents orphan issues)

  • Doesn't affect what IP addresses you see (Cilium's service LB happens at socket/cgroup layer, before TC)

  • Rarely causes conflicts because mermin is passive (TC_ACT_UNSPEC)

Only adjust if you experience specific integration issues with Cilium or other TC programs.

Amazon Elastic Kubernetes Service (EKS)

Prerequisites

  • aws CLI installed and configured

  • eksctl installed (optional but recommended)

  • EKS cluster created

  • kubectl configured for your EKS cluster

Creating an EKS Cluster

Deploying Mermin on EKS

Standard Helm deployment works on EKS:

EKS-Specific Configuration

Network interfaces on EKS nodes (Amazon Linux 2):

For nodes using the VPC CNI plugin with secondary ENIs:

IAM Roles for Service Accounts (IRSA):

Set up IRSA:

Azure Kubernetes Service (AKS)

Prerequisites

  • az CLI installed and configured

  • AKS cluster created

  • kubectl configured for your AKS cluster

Creating an AKS Cluster

Deploying Mermin on AKS

Standard Helm deployment works on AKS:

AKS-Specific Configuration

Network interfaces on AKS nodes:

For nodes using Azure CNI:

Azure AD Pod Identity (optional):

Set up Azure AD Pod Identity:

Cloud-Specific Networking Considerations

Network Policies

All cloud platforms support Kubernetes NetworkPolicies. Ensure Mermin can reach:

Load Balancers

If exposing metrics externally:

GKE:

EKS:

AKS:

Cloud-Specific RBAC and IAM

GKE

Mermin requires Kubernetes RBAC (handled by Helm chart). No additional GCP IAM permissions needed for basic operation.

For advanced features (e.g., accessing GCP APIs):

EKS

Mermin requires Kubernetes RBAC (handled by Helm chart). No additional AWS IAM permissions needed for basic operation.

For advanced features (e.g., accessing AWS APIs):

AKS

Mermin requires Kubernetes RBAC (handled by Helm chart). No additional Azure IAM permissions needed for basic operation.

For advanced features (e.g., accessing Azure APIs):

Performance and Cost Optimization

GKE

  • Use Preemptible/Spot nodes for non-critical Mermin pods (with PodDisruptionBudget)

  • Use node autoscaling to match traffic patterns

  • Consider regional clusters for high availability

EKS

  • Use Spot instances for cost savings (with PodDisruptionBudget)

  • Use Cluster Autoscaler or Karpenter for dynamic scaling

  • Enable Container Insights for monitoring

AKS

  • Use Spot node pools for cost savings

  • Use Cluster Autoscaler for dynamic scaling

  • Enable Container Insights for monitoring

Multi-Region Deployments

For multi-region observability:

  1. Deploy Mermin in each region's cluster

  2. Use region-specific OTLP collectors to reduce cross-region data transfer

  3. Aggregate at central collector if needed

  4. Tag flows with region identifier for differentiation

Example configuration with region tagging:

Monitoring and Logging

Cloud-Native Monitoring

GKE - Cloud Monitoring:

EKS - Container Insights:

AKS - Container Insights:

Troubleshooting Cloud-Specific Issues

GKE Autopilot: "Operation not permitted"

Ensure you're using capabilities instead of privileged: true:

EKS: "Cannot load eBPF program"

Verify kernel version on AL2 nodes:

AKS: "Insufficient permissions"

Ensure managed identity has necessary permissions and AAD Pod Identity is configured correctly.

Next Steps

Last updated