关于kubectl run命令的Kubernetes相关技术疑问咨询

Let's break down each of your questions one by one:

1. Why no Deployment is created after running kubectl run testpod --image=nginx:alpine? Did it only create a Pod? #

This is almost certainly due to Kubernetes version differences changing the default behavior of kubectl run:

• In Kubernetes 1.18 and later: kubectl run defaults to creating a Deployment to manage the Pods.
• In Kubernetes 1.17 and earlier: The command defaults to creating a standalone Pod with no Deployment wrapping it.

To confirm this:

• Run kubectl version to check your client and cluster versions.
• Run kubectl get pods to see if the testpod Pod exists.
• Run kubectl get deployments again to double-check for any related Deployment.

If you're on an older version and want to create a Deployment explicitly, you can use (note: this generator flag is deprecated in newer versions):

kubectl run testpod --image=nginx:alpine --generator=deployment/apps.v1

2. Why does Docker Desktop show two separate instances after running the command? #

The "instances" you see in Docker Desktop are individual Docker containers, and this is expected behavior in Kubernetes:
Every Kubernetes Pod includes a pause container (an infrastructure container) alongside your application container (nginx in this case). The pause container's job is to maintain the Pod's network namespace, allowing all containers in the Pod to share the same network stack (like IP address, ports, etc.).

You can verify this by running docker ps in your terminal: you'll see one container using the nginx:alpine image, and another using a pause image (usually named something like k8s.gcr.io/pause or registry.k8s.io/pause).

3. Why does deleting either instance in Docker Desktop trigger a new instance to be created automatically, even without a Deployment? #

This is thanks to Kubernetes' kubelet component, which runs on every node and is responsible for maintaining Pod states. When you delete a container (either nginx or pause) directly via Docker, kubelet detects that the Pod's state is not matching the desired state (it expects both containers to be running). As part of its self-healing mechanism, kubelet will restart the entire Pod, recreating both containers.

This is different from Deployment-driven recreation: a Deployment would create an entirely new Pod if the old one is deleted, while kubelet restarts the containers within the existing Pod's context. You can see this activity by running kubectl describe pod testpod and checking the "Events" section—you'll see logs of kubelet restarting the containers.

内容的提问来源于stack exchange，提问作者KiddoDeveloper