71–80 of 90 posts
One useful debugging trick I use often is to edit a deployment or pod via `kubectl edit` and update the command to be `tail -f /dev/null` e.g., spec: containers: - command: - bash - -c - tail -f /dev/null (and comment out any liveness or readiness probes) Very useful to then `exec` with a shell in the pod debug things or test out different configs quickly, check the environment etc.
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... It doesn't come with any autocompletion by default, but it's a robust way to deal with multiple clusters. Hope this helps.…
I myself am quite happy with the basics, but have an alias on k=kubectl and set-context that without argument displays the current-context. Before doing anything I rename or edit contexts in .kube/config to have a minimal amount of characters to type for the target ("proj-prod"). Using -l name= is another help in filtering, jsonpath and jq too.. as years ago with using the cli prompts with database products, building up muscle memory also gave me opportunity to grok the concepts at the same time.
After some attempts with different tooling, I came to like kubernetes for what it can do.
Earlier quoted context omitted.
Except with the kernel, you only have to be familiar with the system calls and you don't need a team of people just to run, maintain and upgrade the kernel. That and it tries to make breaking changes on the timescale of decades rather than every other minor release (so, once or twice a year?).
> Except with the kernel, you only have to be familiar with the system calls I think it's safe to assume that any non-trivial use of linux involves non-default configuration. > you don't need a team of people just to run, maintain and upgrade the kernel. My relatively small company employed linux admins before we adopted (on prem) kubernetes. Their work has changed a bit since since then, but it isn't meaningfully mo…
Hosted Kubernetes isn't significantly easier either, as every host is offering you different things as "Kubernetes" and has different ways that you will need to manually intervene to overcome problems.
I'm only telling you this from experience, being years down the rabbit hole already.
Earlier quoted context omitted.
> Except with the kernel, you only have to be familiar with the system calls I think it's safe to assume that any non-trivial use of linux involves non-default configuration. > you don't need a team of people just to run, maintain and upgrade the kernel. My relatively small company employed linux admins before we adopted (on prem) kubernetes. Their work has changed a bit since since then, but it isn't meaningfully mo…
My whole point is that they're not really comparable from a level of effort perspective, despite claims. Hosted Kubernetes isn't significantly easier either, as every host is offering you different things as "Kubernetes" and has different ways that you will need to manually intervene to overcome problems. I'm only telling you this from experience, being years down the rabbit hole already.
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... It doesn't come with any autocompletion by default, but it's a robust way to deal with multiple clusters. Hope this helps.…
I'm lazy and I don't like having to remember "the right way" to run something, so my solution is directories and wrappers. I keep a directory for every environment (dev, stage, prod, etc) for every account I manage. env/ account-a/ dev/ stage/ prod/ account-b/ dev/ stage/ prod/ I keep config files in each directory. I call a wrapper script, cicd.sh , to run certain commands for me. When I want to deploy to stage in a…
(If I were redoing this all from scratch, I would just have my interactive terminal show some status-information above the command after I typed "kubectl "; the context, etc. That way, you know at a glance, and you don't have to tie yourself to the filesystem. And, this could all be recorded in the history, perhaps with a versioned snapshot of the full configuration, so that when this shows up in your history 6 weeks later, you know exactly what you were doing.)
With that in mind, I do feel like the concept of an "environment" has been neglected by UI designers. I never know if I'm on production, staging, private preview, or what; either for my own software, or for other people's software. (For my own, I use "dark reader" and put staging in dark mode and production in unmodified mode. Sure confuses people when I share my screen or file bug reports, though. And, this only works if you have exactly two environments, which is fewer than I actually have. Sigh!)
Earlier quoted context omitted.
I used k9s before and that's an awesome tool. Tho it doesn't help when I want to send a command to my team mate and he just executes them on wrong cluster. It's the problem I want to solve
Create a User/Role for deleting (or whatever dangerous action) resources in prod cluster/namespace. Setup RBAC which allows your employees to impersonate as that user/role using kubectl --as. This way if you send your coworkers a command for dev environment and they try to run it in prod it will fail because they didn’t run kubectl as that impersonated user.
Earlier quoted context omitted.
I used k9s before and that's an awesome tool. Tho it doesn't help when I want to send a command to my team mate and he just executes them on wrong cluster. It's the problem I want to solve
I'm glad to hear that this is a more common problem. When sharing kubectl commands, I always specify the --context flag explicitly so the person using it has to manually edit the context name to whatever they are using before running it.
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... It doesn't come with any autocompletion by default, but it's a robust way to deal with multiple clusters. Hope this helps.…
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 e…