docs: standardize CLI examples and correct linkerd-cni namespace references

[bezarsnba]

This PR improves documentation consistency and correctness across the Linkerd website docs.

It includes two related documentation-only changes:

1. Standardization of CLI command examples by removing shell prompt symbols.

These changes aim to reduce user confusion and improve copy/paste usability without altering any Linkerd behavior.

What changed

1. CLI command standardization

• Removed shell prompt prefixes (e.g. $, ~ $, / $) from bash and sh code blocks
• Ensured all command examples are copy/paste-friendly
• Applied consistently across:
  • CLI reference docs
  • Task guides
  • Troubleshooting sections
  • Edge and stable versions

Why this change

• Shell prompts in docs can cause copy/paste errors and reduce clarity
• Incorrect namespace references can lead to failed commands and user frustration
• These fixes improve documentation accuracy and overall user experience

Scope

• Documentation only
• No functional, behavioral, or API changes
• No impact on Linkerd components or CLI output

Validation

• Reviewed affected pages for consistency and correctness
• Verified corrected commands align with current Linkerd conventions

[kflynn]

@bezarsnba, y'know, I started reviewing this because I love the idea, but I realize that there's a complicating factor. Take a look at this example, from reference/cli/check.md:

linkerd check
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API
...

Contrast with this one, from reference/iptables.md:

kubectl -n <namesppace> logs <pod-name> linkerd-init
# where <pod-name> is the name of the pod
# you want to see the iptables rules for

The first example includes both the command and the output in the same block, so you can't copy & paste that as-is. The second example has no output, so you can.

Overall, in places where we include the command and the output in the same block, it's important to have some way to distinguish what you should type from what you should see.

The best answer here is likely to be to always use two separate blocks, which... that's a massive, massive change. (Even the second example should really be more like

Rules table

...alternatively, if you want to inspect the iptables rules created for a pod, you can retrieve them through the following command (where <pod-name> is the name of the pod for which you want to see the iptables rules):

kubectl -n <namespace> logs <pod-name> linkerd-init

So... I think this is going to need some work. Maybe a first PR fixing typos and such would be the quickest way forward while we figure out how to wrangle the bigger issue?

Thanks for digging into this!

[kflynn]

See comment above. 🙂

[bezarsnba]

@kflynn , I agree that when a code block mixes command + output, removing prompts can make it harder to distinguish what should be executed versus what is expected output. Ideally, these should indeed be split into separate blocks.

That said, I realized this PR started to grow in scope more than intended. To keep it reviewable and focused, I'll limit this PR to cases where the block contains command-only examples, keeping them prompt-free and copy/paste-friendly.

For blocks that include output (or mixed content), I’ll leave them as-is for now and handle standardization separately (either in a follow-up PR or by opening an issue to define a clear convention).

I'll also fix the stray / and minor formatting issues you pointed out.

Thanks again for calling this out. :)

[bezarsnba]

This block contains command-only examples; both commands can be executed sequentially.

[bezarsnba]

Replaced the ❯ prompt with $ to keep shell examples consistent across the docs.

[bezarsnba]

Updated helm repo update to helm repo up for consistency with other upgrade docs.
A broader cleanup to standardize on the official helm repo update command can be done separately.

[bezarsnba]

@kflynn I’ve reviewed the points raised and updated the PR accordingly. I added comments in places that may need a bit more attention or context, based on the feedback provided.

One note on the size of this PR: some of the changes were applied in bulk, which ended up making the PR larger than ideal. In hindsight, I agree this isn’t the best approach for documentation updates. For future work, I plan to break similar changes down into smaller, more focused PRs (for example, by section or by type of code block) to make reviews easier.

Thanks again for the feedback and patience. :)