Kubernetes for Admins — MyAdminDesk

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

A cluster is a place you name before you apply

Kubernetes on this desk is the admin habit: which cluster, which namespace, which identity, and one workload. The command builder drafts kubectl text. The YAML generator drafts a manifest. Neither tool talks to a cluster. You still choose the context.

The context in the prompt must be the cluster in the ticket. A success message from the wrong cluster is the failure. Write the context name before you draft a command that changes anything.

The application identity is not a cluster administrator. A binding that can do everything is a draft you narrow. The manifest guide owns charts and extra objects. This page stops at one namespace and one workload you can explain.

Requests and limits are part of the workload, not a later polish. Write a small request for the lab. The networking companion on the network desk explains cluster paths. You do not open a service to the world to see if the pod started.

One context, one namespace, one manifest you read

Write the context name and the namespace. The namespace says the environment. Draft one workload manifest. Read the image tag, the port, and the identity. Pin the tag the same way the Docker guide asked. A floating tag is still a floating tag inside a cluster.

Draft the smallest command that reads, before any command that writes. A get of the namespace is enough to prove the context. If the name surprises you, stop. Do not apply.

If a service is required for the lab, its type is one you can explain. A load balancer that allocates a public address is a decision, not a default. Prefer a type that stays inside the cluster until the network ticket exists.

The managed cluster guides are where a specific product is administered. Do not create a node pool, an autoscaler, and an ingress in this hour. One of those is a later ticket.

# Kubernetes note. Read the context before any apply.
# One namespace. One workload.
# The app identity is not cluster-admin.
# Pin the image tag.
# A public load balancer is a separate decision.
# prompt-for-this is not a kubeconfig.

A change you can finish

Apply belongs to a lab cluster after the read command showed the right name. One manifest.

Rollback is deleting that lab workload, or applying the previous file you kept. You do not delete the namespace of a shared cluster to undo one file.

Write the context and the namespace.
Draft one manifest and pin the image.
Narrow any administrator binding.
Write requests a lab can live with.
Read with a get before any apply.
Keep a public service out of this hour.
Hand charts and node pools to their guides.

Mistakes that outlive the command

Kubernetes for admins fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Applying to the cluster that happened to be current.
cluster-admin for the application.
A public load balancer as a habit.
An unpinned image tag.
No requests on a workload that will share a node.
A kubeconfig committed or pasted into the ticket.
Deleting a shared namespace as a reset.
An autoscaler and an ingress in the first hour.
A customer manifest you do not understand, applied to learn.
Skipping the Docker tag lesson because the file is YAML.

Decisions to write down before the window

One decision for Kubernetes for admins: The context name matches the ticket. The namespace names the environment. One workload is in the manifest. The image tag is pinned. The identity is not a cluster administrator. Requests are written. A get is the first command. No public service is in this window. The kubeconfig is not in the ticket. Node pools and ingress wait. The manifest guide owns the chart. And one cluster is this window.

The hour you stop

Write the account, the project or subscription, the region, and the clock time before you change anything for Kubernetes for admins. If this account is serving people and you do not have a way back, this hour is a plan. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab account, a lab project, or a lab subscription you administer. You do not point a CLI, a pipeline, or a browser tool at an account you do not run. The tools on this site run in the browser. They draft text. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not an access key, a token, a password, or a kubeconfig you save. The real secret stays in the password store or the platform's secret store. If a file, a log, a ticket, or a pipeline still contains a live secret, stop and rotate it. Then delete the copy.

One change. A network, a virtual machine, a policy, and a pipeline do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous file, the previous plan, or the resource you can delete because it was only a lab.

A second person reads the scope aloud: which account, which region, which name. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

Documentation addresses stay in the note. 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, and 2001:db8::/32 are not prefixes you type into a production network. example.com is not your zone. A generated file that opens 0.0.0.0/0 is a file you edit before it is applied. A source you can name is the rule you keep.

Do not apply a draft you have not read. A cost estimate, a policy, a manifest, and a Terraform plan are reading material. Apply, a resize of a live machine, and a delete of a bucket are later decisions with their own proof. Read the names. Then decide.

Keep the previous file. A generator draft is not the previous file. The previous file is what you put back if the new one is wrong. You practised the path back, including the serial console or a second admin, before you changed a network or a lockout setting.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied stack produces an account nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next account waits until someone else can repeat the proof from the notes. Kubernetes for admins is done for this window when the proof is written, not when a CLI printed a success line.

This page is a planning guide. It is not a vendor manual, not an official standard, not legal advice, and not an audit opinion. If an auditor must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this account alone until that guide has its own window.

Kubernetes checks before an apply

Confirm this before you call the change done: The context was read and it matches. The namespace is a lab name. The manifest is in the ticket. The tag is pinned. Requests are present. No cluster-admin binding is in the file. No public service is in the file. No kubeconfig is in the note. Apply has not happened, or it was the separate lab hour on the right cluster. A previous file exists if you changed one. A second person read the context line. The next object waits. The hostname in the prompt matches the hostname in the ticket for Kubernetes for admins. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for Kubernetes for admins happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.

Companion: Network: Kubernetes Networking Explained.