Tag: kubernetes
The quest for minimalism
Earlier I wrote about the ‘elastic-prune‘ a simple cron-job that lived in Kubernetes to clean up an Elasticsearch database. When I wrote it, I decided to give ‘distroless‘ a whirl. Why distroless? Some will say its because of size, they are searching for the last byte of free space (and thus speed of launching). But,…
Pruning elastics with Kubernetes CronJobs
There was a time you just ran ‘crontab -e’ to make this happen. But, progress, are you still on my lawn? Lets discuss how to solve the specific issue of ‘my database fills up my disk’ in a Cloud Native way. So the situation. I’m using ElasticSearch and fluent-bit for some logging in a Kubernetes cluster.…
Misguided auto-updates in a container world
Let’s say one day you are casually browsing the logs of your giant Kubernetes cluster. You spot this log message: “npm update check failed”. Hmm. Fortunately you have an egress firewall enabled, blocking all outbound traffic other than to your well-known API’s, so you know why it failed. You now worry that maybe some of…
When good containers go bad: github issues are the new release notes
The world is getting faster with shorter cycle times. Software releases, once things that celebrated birthdays are now weekly. Emboldened by the seemingly bullet-proof nature of Kubernetes and Helm, and trying to resolve an issue with an errant log message, I update the nginx-controller. Its easy: helm upgrade nginx-ingress stable/nginx-ingress Moments later it is done.…
The rabbit-hole of log parsing: istio-proxy sidecar log routing and parsing with fluent-bit
Logging. Its the modern day tower of Babel. So I’m using an EFK (Elasticsearch, Fluent, Kibana) stack for log management. Its a common combination (don’t argue with me that logstash is better, its merely different). And as I’ve wandered down the rabbit hole of trying to get semantic meaning from log messages, I’ve learned a…
