Why it s needed CEL expressions are normally only executed at runtime, so it s hard to know what a new expression will actually do without deploying it. Even when test-deploying it it s hard to know if all edge-cases are covered. Why it s hard How to do it
Why go does not have nice backtraces Collecting stacktraces is expensive, so the core language will never implement them for everything.If you need your code to be highly performant then consider making a error wrapper that can be turned on/off based on a environment variable. Simple fix Nicer fix Use a more complete solution like [ ]
No need to rebuild your binary when nothing about it could have changed go build -o foo && ./foo is faster than go run # Makefile BINARY = my-app $(BINARY): $(shell find pkg cmd -type f -name "*.go" ! -name "*_test.go") go.mod go.sum go build -o $(BINARY) cmd/main.go .PHONY: build build: $(BINARY) ## Build binary .PHONY: run run: build ## run ./$(BINARY) --help
Problem When editing metrics in datadog UI (i.e. /metrics/summary) a warning is shown when editing an in-use metric (i.e. a dashboard or monitor uses it). But if that metrics is used by a Kubernetes HorizontalPodAutoscaler, no such warning will show. Solution Generate a dashboard that uses 1 widget for every query an HPA uses.
Often we want to ask what exactly changed about this resource ? especially during or after an incident.The answer usually is check the audit log .But the audit log is very verbose and hard to scan, so here is a ruby rake task to parse the audit log and spit out a nice diff. (Customize to [ ]
kubectl delete -A --all Is very slow, because under the hood it runs 1 delete at a time. (easy to see with -v 8) A much faster way is to talk to the api directly: kubectl delete --raw /api/v1/namespaces/foo/pods That also works with label selectors, for example foo=bar would be: /api/v1/namespaces/foo/pods?labelSelector=foo%3Dbar and deleting everything [ ]
See Gist for a background job that compacts+defrags etcd when the db grew too big, either because the api server was not doing it s job or the db grew too quickly. If this happens often you should consider growing the db size or fixing the api in some other way also add some reporting [ ]
time kubectl get pods /dev/null # 12s time kubect get --raw /api/v1/pods?resourceVersion=0 /dev/null # 2s Just using raw is already faster, but telling the api that you want to read from cache with resourceVersion=0 speeds it up even more and takes load of the api-server. (be careful that reading from cache and using limit= don t [ ]
Kubelet knows which pods are running on the local node, so it s easy/cheap/fast to ask it for the pods metadata. This avoids hitting the api-server which can often be under high load when all Fluentd reporters restart or try to request at the same time. fluent-plugin-kubelet_metadata
We check that all our Service objects match Istios port convention (start with http- or named http for example). For this we developed a policy that rejects any ports that don t match and allow opting out via namespace labels.