Everything useful I know about kubectl

One of the issues I&#x27;ve often seen that my team mates send &quot;right command&quot; to wrong cluster and context. We have a bunch of clusters and it&#x27;s always surprising to see some laptop deployments on ... production cluster.<p>So I wrote this <a href="https:&#x2F;&#x2F;github.com&#x2F;icy&#x2F;gk8s#seriously-why-dont-just-use-kubectl-config" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;icy&#x2F;gk8s#seriously-why-dont-just-use-kube...</a> It doesn&#x27;t come with any autocompletion by default, but it&#x27;s a robust way to deal with multiple clusters. Hope this helps.<p>Edit: Fix typo err0rs

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 &#x2F;dev&#x2F;null`<p>e.g.,<p><pre><code> spec: containers: - command: - bash - -c - tail -f &#x2F;dev&#x2F;null </code></pre> (and comment out any liveness or readiness probes)<p>Very useful to then `exec` with a shell in the pod debug things or test out different configs quickly, check the environment etc.

Nice list. Learned a couple neat things. Thank you!<p>Would like to add that my favorite under-appreciated can&#x27;t-live-without kubectl tool is `kubectl port-forward`. So nice being able to easily open a port on localhost to any port in any container without manipulating ingress and potentially compromising security.

Something this guide misses that is helpful about explain is that it can explain down to primaries types. “K explain po” is great, but “k explain po.spec” will give more details about the spec and its fields. This dot field pattern can go as deep as needed, like pod.spec.volumes.secret.items

How is this command from the page:<p><pre><code> # Lint a Helm chart # Good to put in pre-merge checks $ helm template . | kubeval - </code></pre> different&#x2F; better than &quot;helm lint&quot; (<a href="https:&#x2F;&#x2F;helm.sh&#x2F;docs&#x2F;helm&#x2F;helm_lint&#x2F;" rel="nofollow">https:&#x2F;&#x2F;helm.sh&#x2F;docs&#x2F;helm&#x2F;helm_lint&#x2F;</a>)?

In case you work a lot with k8s, you can take a look as well at k9s, hightly reccomend it. It can save a lot of time with typings, especially to quickly check what pods&#x2F;deployments are running, execute command in pod, describe to understand why did it fail, change cluster &#x2F; namespace and so on

One the most useful things (for me) about kubectl - is moving to k9s cli UI for k8s. Makes daily debugging so much easier.

Break in case of Fire (i.e. rollback to the previous deployment version):<p>kubectl rollout undo deployment &lt;deployment-name&gt;

All that is good and dandy until you run a command and it spews a serialised Go struct instead of a proper error. And, of course, that struct has zero relationship to what the actual error is.<p>Example:<p><pre><code> The Job &quot;export-by-user&quot; is invalid: spec.template: Invalid value: core.PodTemplateSpec{ObjectMeta:v1.ObjectMeta{Name:&quot;&quot;, GenerateName:&quot;&quot;, Namespace:&quot;&quot;, SelfLink:&quot;&quot;, UID:&quot;&quot;, ResourceVersion:&quot;&quot;, Generation:0, CreationTimestamp:v1.Time{Time:time.Time{wall:0x0, ext:0, loc:(*time.Location)(nil)}}, DeletionTimestamp:(*v1.Time)(nil), DeletionGracePeriodSeconds:(*int64)(nil), Labels:map[string]string{&quot;controller-uid&quot;:&quot;416d5527-9d9b-4d3c-95d2-5d17c969be19&quot;, &quot;job-name&quot;: &quot;export-by-user&quot;, Annotations:map[string]string(nil), OwnerReferences:[]v1.OwnerReference(nil), Finalizers:[]string(nil), ClusterName:&quot;&quot;, ManagedFields:[]v1.ManagedFieldsEntry(nil)}, Spec:core.PodSpec{Volumes:[]core.Volume(nil), InitContainers:[]core.Container(nil), Containers:[]core.Container{core.Container{Name:&quot;.... </code></pre> And it just goes on.<p>The actual error? The job is already running and cannot be modified

I’d love to know the easiest way to answer this question: “what IP address and port is the microservice pod the CI server just deployed listening on?”

I have been using kubectl + zsh for quite a while.<p>But now my choice is Intellij (or other IDEs from JetBrains) + Lens, which I find more productive and straightforward (more GUI, fewer commands to memorize). Here&#x27;s my setup and workflow:<p>1. For each repository, I put the Kubernetes deployment, service configurations, etc. in the same directory. I open and edit them with Intellij.<p>2. There&#x27;s also a centralized repository for Ingress, Certificate, Helm charts, etc. I also open with Intellij. Spend some time to organize Kubernetes configs really worth it. I&#x27;m working with multiple projects and the configs gets overwhelming very quickly.<p>3. Set shortcuts for applying and deleting Kubernetes resources for current configs for Intellij. So I can create, edit, and delete resources in a blink.<p>4. There&#x27;s a Kubernetes panel in Intellij for basic monitoring and operations.<p>5. For more information and operations, I would use Lens instead of Intellij. The operations are very straightforward, I can navigate back and forth, tweak configurations much faster than I could with the shell command only.

Want a crude way to see pods run on a node with the READY, STATUS and RESTARTS fields instead of the `kubectl describe node` output?<p>kubectl get po --all-namespaces -o wide | grep $NODE_NAME<p>Of course becomes unbearably slow, the more pods you have

Every time I&#x27;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.<p>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.<p>So I put together this &quot;cheat sheet&quot; for us internally and thought I&#x27;d share it for anyone interested.<p>Pull requests welcome for updates: <a href="https:&#x2F;&#x2F;github.com&#x2F;wrble&#x2F;public&#x2F;blob&#x2F;main&#x2F;aws-instance-types.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;wrble&#x2F;public&#x2F;blob&#x2F;main&#x2F;aws-instance-types...</a><p>Did I miss anything?

This is a really great article, thanks for sharing!

&gt; kubectl is self-documenting, which is another reason why it&#x27;s 100x better than a UI<p>A console tool has a UI, it&#x27;s the shell. And GUIs can be self-documenting too: tool tips, help bars, interactive prompts, manuals.

I would add one more important point about kubectl?<p>If you don&#x27;t work at Google, you don&#x27;t need a complexity of kubernetes at all, so better forget everything you already know about it. The company would be grateful.<p>Joke aside, trying to sell something to the masses that could potentially benefit only 0.001% of the projects is just insincere.<p>Pure CV pump and dump scheme.