pod相关面试题总结（持续更新）-CFANZ编程社区

1:当一个Pod有多个容器时，如果连接到指定的容器？

#查看当前空间下的pod
[root@master210 pods]# kubectl get pods
NAME                   READY   STATUS    RESTARTS   AGE
linux85-nginx-tomcat   2/2     Running   0          63s
[root@master210 pods]# 
[root@master210 pods]# kubectl exec -it linux85-nginx-tomcat -- sh  # 默认连接到第一个容器
Defaulted container "nginx" out of: nginx, tomcat
/ # 
/ # 
/ # 
[root@master210 pods]# kubectl exec -it linux85-nginx-tomcat -c nginx -- sh  # 连接nginx容器
/ # 
[root@master210 pods]# kubectl exec -it linux85-nginx-tomcat -c tomcat -- sh  # 连接tomcat容器
/usr/local/tomcat #

可通过-c 容器名指定
早期版本中，可能没有提示Pod容器的名称，可以采用以下三种方式查看容器名称。
cat 02-nginx-tomcat.yaml
kubectl describe pod linux85-nginx-tomcat
kubectl get pods linux85-nginx-tomcat -o yaml

2: 如果查看一个Pod最近20分钟的日志?

[root@master210 pods]# kubectl logs -c nginx -f  --timestamps --since=20m linux85-nginx-tomcat 
 -c:
	指定要查看的容器名称。
 -f:
	实时查看日志。
 --timestamps :
	显示时间戳相关信息。
 --since=20m 
	查看最近20分钟内的日志

3: 如何查看一个Pod上一个容器的日志，上一个挂掉的容器日志？

[root@master210 pods]# kubectl logs -c tomcat -f  --timestamps -p  linux85-nginx-tomcat

4: 使用kubectl logs无法查看日志是什么原因，如何让其能够查看呢?

使用"kubectl logs"查看的是容器的标准输出或错误输出日志，如果想要使用该方式查看，需要将日志重定向到/dev/stdout或者/dev/stderr。

5: 如何实现Pod的容器的文件和宿主机之间相互拷贝?

[root@master210 pods]# kubectl get pods
NAME               READY   STATUS    RESTARTS   AGE
linux85-game-014   1/1     Running   0          3m10s
[root@master210 pods]# kubectl cp linux85-game-014:/start.sh /tmp/1.sh  # 拷贝文件
[root@master210 pods]# kubectl cp linux85-game-014:/etc /tmp/2222  # 拷贝目录
[root@master210 pods]# ll /tmp/
total 16
-rw-r--r--  1 root root 3369 Apr 13 17:01 1.sh
drwxr-xr-x 20 root root 4096 Apr 13 17:02 2222
    - 将宿主机的文件拷贝到Pod的容器中
[root@master210 pods]# kubectl cp 01-nginx.yaml linux85-game-014:/
[root@master210 pods]# 
[root@master210 pods]# kubectl cp /tmp/2222/ linux85-game-014:/
[root@master210 pods]# 
[root@master210 pods]# kubectl exec linux85-game-014 -- ls -l /
total 24
-rw-r--r--    1 root     root           301 Apr 13 09:03 01-nginx.yaml
drwxr-xr-x   20 root     root          4096 Apr 13 09:04 2222

6: 镜像下载策略有哪些？请分别说明？

在 Kubernetes 中，镜像下载策略（Image Pull Policy）用于决定在创建 Pod 时如何从镜像仓库中拉取容器镜像。Kubernetes 提供了三种主要的镜像下载策略，分别是：
Always
IfNotPresent
Never

Always
说明: 每次启动 Pod 时，Kubernetes 总是从镜像仓库拉取最新版本的镜像，即使本地已经存在相同的镜像版本。
使用场景:
适用于开发和测试环境，确保容器每次启动时都使用最新的镜像。
适用于镜像标签为 latest 的场景，因为 latest 标签不固定，镜像内容可能会不断更新。
指定方式: 在 Pod 配置文件中设置 imagePullPolicy: Always。
默认行为: 当镜像标签为 latest 时，Kubernetes 默认使用 Always 策略。
例：

spec:
  containers:
  - name: my-container
    image: my-app:latest
    imagePullPolicy: Always

IfNotPresent
说明: 如果本地已经存在指定的镜像，则不会从镜像仓库拉取镜像。只有在本地不存在镜像时，才会尝试从仓库中拉取。
使用场景:
适用于生产环境，确保只有在本地没有镜像的情况下才会下载镜像，从而减少镜像拉取时间和带宽消耗。
适用于明确版本标签的镜像（例如 my-app:v1.0.0），这种镜像的内容是固定的，通常不需要每次都拉取。
指定方式: 在 Pod 配置文件中设置 imagePullPolicy: IfNotPresent。
默认行为: 当镜像标签不是 latest 且没有指定 imagePullPolicy 时，默认使用 IfNotPresent 策略。
例：

spec:
  containers:
  - name: my-container
    image: my-app:v1.0.0
    imagePullPolicy: IfNotPresent

Never
说明: Kubernetes 不会从镜像仓库拉取镜像，必须确保镜像已经存在于本地。如果本地不存在镜像，则会导致 Pod 启动失败。
使用场景:
适用于镜像已经手动预先下载到所有节点的场景。
在高安全性或离线环境中，可能需要完全避免从镜像仓库拉取镜像。
指定方式: 在 Pod 配置文件中设置 imagePullPolicy: Never。
注意: 使用该策略时，如果节点上没有镜像，Pod 会报错，无法启动。
例：

spec:
  containers:
  - name: my-container
    image: my-app:v1.0.0
    imagePullPolicy: Never

默认行为总结:
如果镜像标签为 latest，则 imagePullPolicy 默认为 Always。
如果指定了镜像标签并且不是 latest，则默认使用 IfNotPresent。
明确设置的 imagePullPolicy 将会覆盖默认行为。
使用场景总结：
Always: 当你需要每次启动容器时都拉取最新镜像，例如开发、测试或者 latest 标签场景。
IfNotPresent: 当你希望尽量使用本地已有镜像，减少拉取时间，通常适用于生产环境中的稳定版本镜像。
Never: 当你已经预先在节点上准备好镜像，并且不希望 Kubernetes 再次拉取镜像。

7: Pod的容器重启策略有哪些？请简要说明？

Kubernetes 中 Pod 的容器有三种重启策略：
Always：容器无论退出状态如何，始终会重启。这是默认设置。适用于需要持续运行的应用。
示例：

apiVersion: v1
kind: Pod
metadata:
  name: always-restart
spec:
  containers:
  - name: my-container
    image: my-image
    restartPolicy: Always

OnFailure：只有当容器以非零状态退出时，才会重启。适用于需要在失败时重新尝试的批处理任务。正常退出时不会重启容器，异常退出时，会重启容器。
示例：

apiVersion: v1
kind: Pod
metadata:
  name: on-failure-restart
spec:
  containers:
  - name: my-batch-job
    image: my-batch-image
    restartPolicy: OnFailure

Never：容器退出后不进行重启。适用于一次性任务，不希望重启的场景。
示例：

apiVersion: v1
kind: Pod
metadata:
  name: never-restart
spec:
  containers:
  - name: my-one-time-job
    image: my-job-image
    restartPolicy: Never

8: 如何向Pod的指定容器传递环境变量？有哪些方式，请简要说明？

直接在 Pod 定义中设置：在 Pod 的 YAML 配置文件中，可以直接为容器定义环境变量

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    env:
    - name: MY_ENV_VAR
      value: "my_value"

从 ConfigMap 中获取：可以将环境变量存储在 ConfigMap 中，然后在 Pod 中引用。

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  MY_ENV_VAR: "my_value"

---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    env:
    - name: MY_ENV_VAR
      valueFrom:
        configMapKeyRef:
          name: my-config
          key: MY_ENV_VAR

从 Secret 中获取：对于敏感信息（如密码），可以使用 Secret 存储，并在 Pod 中引用。

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  MY_SECRET_VAR: bXlfc2VjcmV0X3ZhbHVl # base64 编码

---
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    env:
    - name: MY_SECRET_VAR
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: MY_SECRET_VAR

从 Downward API 获取：可以使用 Downward API 将 Pod 的元数据作为环境变量传递给容器。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name

9: 同一个Pod如何实现数据持久化？如何实现数据共享？跨节点的Pod如何实现数据共享呢？

使用 emptyDir 实现数据持久化和共享
emptyDir 是一种临时存储卷，Pod 在运行时会创建，并在 Pod 删除时删除。可以用于容器间的数据共享。
emptyDir 适合用于同一个 Pod 内的多个容器之间共享数据。
数据在 Pod 删除后会丢失。

apiVersion: v1
kind: Pod
metadata:
  name: linux85-volume-emptydir-001
spec:
  volumes:
    - name: data01
      emptyDir: {}  # 创建一个空的临时存储卷
  containers:
  - name: web
    image: nginx:1.20.1-alpine
    volumeMounts:
    - name: data01
      mountPath: /usr/share/nginx/html  # 挂载到指定路径
  - name: linux
    image: alpine:latest
    stdin: true
    volumeMounts:
    - name: data01
      mountPath: /edu-data  # 共享同一个 emptyDir

使用 hostPath 实现数据持久化
hostPath 是一种将宿主机文件系统中的某个目录挂载到容器中的方式，适合快速存取宿主机的数据。
hostPath 可用于快速访问宿主机的数据。
注意，这种方式不适合在多个节点间共享数据。

apiVersion: v1
kind: Pod
metadata:
  name: linux85-volume-hostpath-001
spec:
  volumes:
    - name: data02
      hostPath:
        path: /edu-data  # 宿主机路径
  containers:
  - name: web
    image: nginx:1.20.1-alpine
    volumeMounts:
    - name: data02
      mountPath: /usr/share/nginx/html  # 挂载宿主机路径

使用 NFS 实现数据共享和持久化
NFS（网络文件系统）可以实现跨节点的数据共享，适合需要在多个 Pod 之间共享数据的场景。

部署 NFS 服务器，可以参考：
nfs文件服务器部署

apiVersion: v1
kind: Pod
metadata:
  name: linux85-volume-nfs-web
spec:
  nodeName: k8s232.oldboyedu.com
  volumes:
    - name: data
      nfs:
        server: 192.168.29.110  # NFS 服务器地址
        path: /data/kubernetes/volume-nfs  # NFS 导出路径
  containers:
  - name: web
    image: nginx:1.20.1-alpine
    volumeMounts:
    - name: data
      mountPath: /usr/share/nginx/html

10:如何对容器进行资源限制

对容器进行资源限制可以确保每个容器在运行时不会占用过多的 CPU 和内存，从而保护其他容器和系统的稳定性。Kubernetes 通过在 Pod 定义中使用 resources 字段来设置资源限制。以下是如何设置 CPU 和内存资源限制的示例：

apiVersion: v1
kind: Pod
metadata:
  name: linux85-stress-003
spec:
  containers:
  - name: stress
    image: linux-tools:v0.1
    args:
    - "tail"
    - "-f"
    - "/etc/hosts"
    resources:
      requests:
        memory: "256Mi"  # 请求的内存
        cpu: "500m"      # 请求的 CPU
      limits:
        memory: "512Mi"  # 限制的内存
        cpu: "1"         # 限制的 CPU

resources:
requests: 指定容器启动时需要的资源量。Kubernetes 会根据请求的资源量来调度 Pod。如果没有足够的资源可用，Pod 将不会被调度。
memory: 指定请求的内存量（例如，256Mi）。
cpu: 指定请求的 CPU 核心数（例如，500m 表示 0.5 核心）。
limits: 指定容器能够使用的最大资源量。超过限制的部分将被限制或终止。
memory: 指定限制的内存量（例如，512Mi）。
cpu: 指定限制的 CPU 核心数（例如，1 表示 1 核心）