测试容器并不是什么都没有的容器，只是它没有我们期望的常驻进程。我们常用它来做一些测试。
举个例子，在《研发工程师玩转Kubernetes——自动扩缩容》中我们使用本地wrk进行了压力测试。如果我们希望进入容器手工调用wrk，该怎么做呢？

错误的案例

虽然下面这个清单文件的镜像中包含了wrk程序，但是它没有启动一个常驻进程。导致运行这个Pod一直会报错“Back-off restarting failed container”，Reason是CrashLoopBackOff。

apiVersion: v1
kind: Pod
metadata:
  name: wrk
  labels:
    name: wrk
spec:
  containers:
  - name: wrk-container
    image: localhost:32000/wrk:v1

kubectl describe pod wrk

Name:             wrk
Namespace:        default
Priority:         0
Service Account:  default
Node:             fangliang-virtual-machine/192.168.137.248
Start Time:       Mon, 29 May 2023 14:30:37 +0800
Labels:           name=wrk
Annotations:      cni.projectcalico.org/containerID: 75a18bfd3f3d83dd14b7bc9655343842d9bac20a4c52a7ee75932013be395e01
                  cni.projectcalico.org/podIP: 10.1.62.178/32
                  cni.projectcalico.org/podIPs: 10.1.62.178/32
Status:           Running
IP:               10.1.62.178
IPs:
  IP:  10.1.62.178
Containers:
  wrk-container:
    Container ID:   containerd://80d5186f701de4ccd861dc84078290250f3452a90ed226cb246a4f6b9aab5ef6
    Image:          localhost:32000/wrk:v1
    Image ID:       localhost:32000/wrk@sha256:3548119fa498e871ac75ab3cefb901bf5a069349dc4b1b92afab8db4653f6b25
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Mon, 29 May 2023 14:31:17 +0800
      Finished:     Mon, 29 May 2023 14:31:17 +0800
    Ready:          False
    Restart Count:  3
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-ld6j6 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  kube-api-access-ld6j6:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  54s                default-scheduler  Successfully assigned default/wrk to fangliang-virtual-machine
  Normal   Pulled     14s (x4 over 53s)  kubelet            Container image "localhost:32000/wrk:v1" already present on machine
  Normal   Created    14s (x4 over 53s)  kubelet            Created container wrk-container
  Normal   Started    14s (x4 over 53s)  kubelet            Started container wrk-container
  Warning  BackOff    2s (x6 over 52s)   kubelet            Back-off restarting failed container wrk-container in pod wrk_default(588fb4f3-d649-4570-b64c-a4eff748417d)

正确的案例

我们只要启动一个常驻进程就可以解决这个问题。
在linux系统中，/dev/null是一个非常特殊的文件，它会抛弃所有写入其中的数据。于是我们持续查看这个文件的写入，就可以制造一个常驻进程，而且没有其他额外的影响。

command: [“/bin/bash”, “-ce”, “tail -f /dev/null”]

即把清单文件改成如下

apiVersion: v1
kind: Pod
metadata:
  name: wrk
  labels:
    name: wrk
spec:
  containers:
  - name: wrk-container
    image: localhost:32000/wrk:v1
    command: ["/bin/bash", "-ce", "tail -f /dev/null"]

测试

创建Pod

kubectl create -f wrk_pod.yaml

pod/wrk created

登录容器

kubectl exec wrk -c  wrk-container -it /bin/bash

执行指令

wrk -t10 -c10 -d10  http://192.168.137.248:30000

可见，我们已经可以在这个测试容器中执行我们想执行的指令了。

参考资料

• https://blog.csdn.net/yztezhl/article/details/125421316
• https://linuxhint.com/what_is_dev_null/