CIDR Subnet Calculator
Parse CIDR blocks, compute ranges, split into smaller subnets, and check whether an IP lives inside a network.
Open toolPlan Kubernetes requests and limits without guessing. See node-fit, cluster totals, and recommended burst.
Runs locally in your browser
// observed peak usage
// cluster totals for 3 replicas
975m
1.95Gi
resources:
requests:
cpu: "325m"
memory: "666Mi"
limits:
memory: "1.30Gi"Measure actual peak usage from a running Pod with kubectl top pod or Prometheus. Guessing leads to overprovisioning (wastes money) or underprovisioning (evictions and OOMKills).
Workloads have bursts your metrics didn't capture. 25-50% headroom is typical. If traffic is unpredictable, lean higher. If cost matters more than reliability, lean lower.
Kubernetes throttles containers that exceed their CPU limit, even when the node has idle CPU. This can cause tail-latency spikes. Many teams set CPU requests (for scheduling fairness) and leave CPU limits unset. Memory limits are different because memory can't be throttled and has to be bounded somehow.
Requests are what Kubernetes guarantees a container. The scheduler uses them to place Pods on nodes. Limits are the hard ceiling; exceeding them for CPU causes throttling, for memory causes an OOMKill.
This is debated. CPU limits cause throttling under load, which can hurt latency even when the node has spare capacity. Many teams set CPU requests but leave limits off.
A common rule of thumb is 25-50% headroom over measured peak usage. The calculator lets you set a multiplier so you can size from real metrics and add buffer explicitly.
Tools are ported from DevOps Daily under the MIT license.View original
Parse CIDR blocks, compute ranges, split into smaller subnets, and check whether an IP lives inside a network.
Open toolInspect any JWT in your browser. Nothing is sent to a server.
Open toolEncode or decode base64 and URL strings in real time.
Open tool