Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Every time I'm starting a new service to run internally or reviewing something we have going, I find myself struggling to find the right instance type for the needs.
For instance, there are three families (r, x, z) that optimize RAM in various ways in various combinations and I always forget about the x and z variants.
So I put together this "cheat sheet" for us internally and thought I'd share it for anyone interested.
Pull requests welcome for updates: https://github.com/wrble/public/blob/main/aws-instance-types...
Did I miss anything?
That one has annoyed people for a long time. See https://github.com/kubernetes/kubernetes/issues/48388.
I'm pretty sure if you have the time to make a PR to fix it, it would be welcome.
One of the issues I've often seen that my team mates send "right command" to wrong cluster and context. We have a bunch of clusters and it's always surprising to see some laptop deployments on ... production cluster.
So I wrote this https://github.com/icy/gk8s#seriously-why-dont-just-use-kube... I doesn't come with any autocompletion by default, but it's an robust way to deal with multiple clusters. Hope this helps.
Agree, this is a huge pain point when dealing with multiple clusters. I wrote a wrapper for `kubectl` that displays the current context for `apply` & `delete` and prompts me to confirm the command. It's not perfect, but it's saved me a lot of trouble already — but encouraging other members of the team to have a similar setup is another story.
Here's the script (along with a bunch of extra utils): https://github.com/pch/dotfiles/blob/master/kubernetes/utils...
I wrote a convoluted tool for this problem which isolates kubectl environments in docker containers: https://github.com/forestgagnon/kparanoid.
This approach allows the convenience of short, context-free commands without compromising safety, because the context info in the shell prompt can be relied on, due to the isolation.
There are some things which don't work well inside a docker container (port-forwarding for example), but it does make it simple to have isolated shell history, specific kubectl versions, etc.