Tính subnet CIDR
Phân tích dải CIDR, tính dải địa chỉ, chia nhỏ subnet và kiểm tra một IP có nằm trong mạng hay không.
Mở công cụLên kế hoạch requests và limits cho Kubernetes thay vì đoán. Xem độ vừa node, tổng cluster và mức burst khuyến nghị.
Chạy cục bộ trên trình duyệt
// 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.
Các công cụ được port từ DevOps Daily theo giấy phép MIT.Xem bản gốc
Phân tích dải CIDR, tính dải địa chỉ, chia nhỏ subnet và kiểm tra một IP có nằm trong mạng hay không.
Mở công cụXem nội dung bất kỳ JWT nào ngay trên trình duyệt. Không gửi gì lên server.
Mở công cụMã hoá hoặc giải mã chuỗi base64 và URL theo thời gian thực.
Mở công cụ