Kubernetes Operations: Scaling, Network Policy and Falco

Production readiness is behavior you can demonstrate

A Kubernetes version upgrade is one operational task. Capacity, network access, and incident detection need separate evidence. This article keeps its original URL but focuses on those operating concerns rather than presenting a release announcement or an unverified account of running a large commercial fleet.

The examples below illustrate configuration boundaries. They do not establish a two-minute scaling result, a measured cost reduction, regulatory compliance, or immunity to lateral movement. Test the controls against the versions and workload in your own environment.

Karpenter: define eligible capacity

A Karpenter NodePool constrains the nodes that may be provisioned. Workload requests, architecture, taints, availability, and the referenced provider NodeClass all affect scheduling. Configuring an ARM pool does not make an x86-only image runnable on it. Karpenter NodePool documentation.

This example targets the karpenter.sh/v1 schema. It assumes an installed compatible controller and a separately configured AWS EC2NodeClass named application, including suitable IAM, subnet, security-group, and AMI settings. It is an illustrative manifest, not a complete cluster installation or a tested production deployment.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: application-arm
spec:
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: application
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["arm64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
  limits:
    cpu: "100"

The capacity limit is an example to adapt, not a cost guarantee. Keep the initial exercise small. Verify image architecture, pending-pod reasons, node readiness, and application readiness. Spot capacity can be introduced deliberately with interruption handling and suitable fallback capacity; it should not appear in a critical workload merely because a tutorial used it.

Measure the full scaling path: demand signal, scheduling, instance allocation, node registration, image pull, and readiness. Neither a controller choice nor an instance family establishes a universal provisioning time. Compare a candidate design with the current one under the same workload and constraints.

NetworkPolicy: test denied traffic as well as allowed traffic

Kubernetes NetworkPolicy needs a network implementation that enforces it. Policies are additive; a default-deny policy does not override another policy that permits a connection. Standard NetworkPolicy also has scope limitations and is not a complete security boundary for every kind of host traffic. Kubernetes NetworkPolicy documentation.

This namespaced example selects all pods and isolates both ingress and egress. Apply it only in a controlled test namespace after planning the required allow rules, including DNS and operational dependencies.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: application-test
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Create a connection matrix before rollout: intended source, destination, port, and reason. Test one allowed connection and one denied connection for each important boundary. A manifest being accepted by the API server is not evidence that the data plane enforced it.

Istio mTLS: authentication is not authorization

Istio PeerAuthentication controls transport-level authentication. For workloads covered by an appropriate mesh configuration, STRICT mode requires mutual TLS. Current documentation uses security.istio.io/v1. Mesh mode and scope matter; read the requirements for the deployed configuration. Istio PeerAuthentication reference.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: require-mtls
  namespace: application-test
spec:
  mtls:
    mode: STRICT

An authenticated workload can still be the wrong caller. Add authorization rules for the identities and operations that should be allowed. Verify both encrypted transport and denied unauthorized requests. Do not claim that mTLS alone prevents a compromised, already-authorized service from abusing its privileges.

Falco: detection needs an explicit response path

Falco evaluates event data against rules and emits security detections. Deploying it does not automatically create a response controller, cordon a node, isolate a pod, or send alerts to a particular team's chat. Those integrations and permissions must be configured and tested separately. Falco concepts.

For an authorized test, choose a harmless event that a specific rule should detect. Confirm the event contains enough context to identify the workload, reaches the intended destination, and has an owner who can interpret it. Review expected operational activity to reduce noise. If automated containment is proposed, assess its potential to interrupt legitimate workloads before enabling it.

Evidence to retain

The portfolio's WhiteFriday scaling blueprint and NEZEN platform project provide related architectural context. Their existence is not a substitute for measured production results. Keep configuration, test conditions, failure cases, and unresolved limits together when describing an operational system.

Sardar Mukhshaf

Full-Stack & DevOps Engineer

I build scalable web applications, secure backend systems, and production-ready cloud infrastructure. My engineering focus spans interface design, API architecture, deployment pipelines, and observability. Follow for more deep dives into system architecture, performance engineering, and emerging technologies.

ShareTwitterLinkedInCopy Link