[面试] 15道最典型的k8s面试题-Toy模板网

这篇具有很好参考价值的文章主要介绍了[面试] 15道最典型的k8s面试题。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

在 Kubernetes 中，有以下常见的资源对象：

Pod（Pod）：容器的最小调度单位，可以包含一个或多个相关容器。
Deployment（部署）：用于控制 Pod 的创建、更新和删除，确保应用的稳定运行。
Service（服务）：为一组具有相同标签的 Pod 提供统一访问入口，并提供负载均衡能力。
Ingress（入口）：通过定义规则来管理从外部访问集群内 Service 的流量。
ConfigMap（配置映射）：存储应用程序的配置数据，以键值对的形式提供给容器。
Secret（密钥）：用于存储敏感数据，如密码、令牌等，并将其安全地传递给容器。
Volume（卷）：在容器之间共享和持久化数据的抽象概念。
StatefulSet（有状态副本集）：管理有状态应用程序的创建、更新和删除，确保每个 Pod 都有唯一的网络标识和稳定的持久化存储。
DaemonSet（守护进程集）：确保集群中的每个节点都运行一个 Pod 实例，用于在整个集群中运行系统级任务。
Job（作业）：用于创建一次性任务，会运行一个或多个 Pod 直到完成指定的工作。
CronJob（定时作业）：根据用户定义的时间表定期运行 Job。
Namespace（命名空间）：用于在集群内部分隔资源，实现多租户的隔离和资源管理。
ServiceAccount（服务账户）：与 Pod 关联的身份验证信息，并授予 Pod 访问其他资源的权限。

除了上述常见的资源对象之外，Kubernetes 还支持许多其他类型的资源对象，如 PersistentVolume、PersistentVolumeClaim、ReplicaSet、HorizontalPodAutoscaler 等。每个资源对象都有不同的用途和特点，可以根据实际需求选择适合的资源对象来管理和部署应用程序。

DaemonSet的使用场景
DaemonSet 是 Kubernetes 中一种用于在集群中的每个节点上运行一个副本的控制器。它适用于以下场景：

在每个节点上运行守护进程：如果您的应用程序需要在集群中的每个节点上运行守护进程，例如日志收集代理、监视代理或网络代理等，那么可以使用 DaemonSet 来确保在每个节点上都有一个副本运行。DaemonSet 将自动在新加入集群的节点上创建和调度新的副本。

节点级别的任务或服务：有些应用程序或服务只需在每个节点上运行一个副本，而不需要进行负载均衡或复制。DaemonSet 可以确保每个节点上都有该任务或服务的一个副本运行，这对于节点级别的系统管理任务或监视任务非常有用。

节点特定的配置或资源约束：如果您的应用程序在不同的节点上需要不同的配置或资源约束（例如 CPU 和内存限制），则可以使用 DaemonSet 来针对每个节点应用不同的配置和资源约束。

扩展和自动化操作：DaemonSet 可以与自动扩展和自动修复机制结合使用，使得当集群的节点数量增加或减少时，自动调整 DaemonSet 的副本数量，并确保在每个节点上维持所需的副本数量。
总之，DaemonSet 在需要在集群的每个节点上运行一个副本的场景下非常有用，特别适合于守护进程、节点级别任务和服务、节点特定配置以及扩展和自动化操作的需求。

1.什么是 Kubernetes？它的主要特点是什么？

Kubernetes 是一个开源的容器编排系统，用于自动化部署、扩展和管理容器应用程序。它可以帮助我们更轻松地部署和管理容器化应用程序，并提供高可用性、弹性、自动化和安全性等特性。

2. Kubernetes 中的 Pod 是什么？它的作用是什么？

Pod 是 Kubernetes 最小的可部署单元，它可以包含一个或多个紧密耦合的容器。Pod 的主要作用是提供一个环境，让容器可以共享网络和存储资源，并且它还提供了容器间通信和生命周期管理等功能。

3.Kubernetes 中的 Deployment 和 StatefulSet 有何区别？

Deployment 用于部署无状态应用程序，而 StatefulSet 用于部署有状态应用程序。StatefulSet 可以保证应用程序的唯一性和顺序性，同时支持有状态服务的动态扩展和缩减等操作。

4.什么是 Kubernetes 中的 Service？它的作用是什么？

Service 是 Kubernetes 中的一种资源对象，它负责为 Pod 提供一个固定的 IP 地址和 DNS 记录，并将请求转发给相应的 Pod。Service 的主要作用是提供网络访问和负载均衡。

5.请解释一下 Kubernetes 中的水平扩展（Horizontal Pod Autoscaling）是什么，以及它是如何工作的？

水平扩展是一种根据应用程序的负载自动调整 Pod 数量的方法。Kubernetes 的 Horizontal Pod Autoscaling(HPA) 功能可以根据 CPU 利用率、内存利用率等指标自动调整 Pod 数量，从而实现负载均衡和避免资源浪费。

6. Kubernetes 中的 ConfigMap 和 Secret 有何区别，分别用于什么目的？

ConfigMap 和 Secret 都用于将配置信息注入到容器中。其中，ConfigMap 主要用于保存配置文件、环境变量等普通字符串类型的配置信息，而 Secret 则主要用于保存敏感信息如密码、证书等加密数据。

7.如何在 Kubernetes 中进行滚动更新（Rolling Update）？

使用 Rolling Update 可以在不中断服务的情况下逐步更新应用程序。在 Kubernetes 中，可以通过修改 Deployment 的版本号等方式来进行滚动更新。通过逐步替换旧的 Pod 实例来达到更新的效果。

示例

编写 Deployment 文件：创建一个 Deployment YAML 文件来定义你的应用程序。下面是一个示例文件

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3                     # 定义副本数
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:latest       # 容器镜像
        ports:
        - containerPort: 8080     # 容器监听的端口

应用 Deployment：使用 kubectl apply 命令来创建或更新 Deployment。

kubectl apply -f deployment.yaml

验证 Deployment：使用 kubectl get deployments 命令验证 Deployment 是否成功创建，并确保所有 Pod 处于运行状态。

kubectl get deployments

kubectl get pods

更新镜像版本：更新 Docker 镜像版本以进行滚动更新。可以通过更新 Deployment 文件中的 image 字段来实现，

    spec:
      containers:
      - name: my-app
        image: my-app: new-version   # 更新为新的镜像版本
        ports:
        - containerPort: 8080

然后再次执行 kubectl apply 命令。

kubectl apply -f deployment.yaml

监控滚动更新进度：使用 kubectl rollout status 命令来监控滚动更新的进度。

kubectl rollout status deployment/my-app

回滚到旧版本（可选）：如果滚动更新出现问题，可以回滚到旧版本。使用 kubectl rollout undo 命令进行回滚操作。

kubectl rollout undo deployment/my-app

8.什么是命名空间（Namespace），以及它在 Kubernetes 中的作用是什么？

命名空间是 Kubernetes 中用于隔离资源的一种机制。它可以将不同的资源组织到不同的命名空间中，以便更好地管理和隔离这些资源。命名空间还提供了一定的访问控制机制，可以限制用户和应用程序对资源的访问权限。

9.如何在 Kubernetes 中使用存储卷（Volume）？

在 Kubernetes 中，可以通过声明式方式或者命令式方式来定义和管理存储卷。通过存储卷，可以将数据持久化到某种外部存储设备中，如云盘、本地磁盘等。

10.Kubernetes 中的调度器（Scheduler）负责什么任务？

调度器是 Kubernetes 中的一个核心组件，它负责选择合适的节点来运行 Pod。调度器根据节点的资源利用率、节点标签、Pod 的要求等因素来做出决策，以便将 Pod 调度到最优的节点上运行。

11.解释一下 Kubernetes 中的亲和性调度（Affinity Scheduling）和反亲和性调度（Anti-Affinity Scheduling）。

亲和性调度和反亲和性调度是 Kubernetes 中常用的 Pod 调度策略。亲和性调度可以将 Pod 调度到拥有特定标签的节点上，反亲和性调度则可以避免将多个相似的 Pod 调度到同一个节点上，以确保高可用性和容错性。

12.什么是 DaemonSet？它在 Kubernetes 集群中的作用是什么？

DaemonSet 是一个特殊的控制器，它负责将 Pod 在集群中的每个节点上启动和管理。DaemonSet 的主要作用是在所有节点上部署后台服务或者特定的网络代理。

13.Kubernetes 中的控制器（Controller）有哪些类型？请举例说明。

在 Kubernetes 中，常见的控制器类型包括 Deployment、StatefulSet、DaemonSet、Job 等。Deployment 可以进行滚动更新、回滚等操作，StatefulSet 可以保证有状态应用程序的唯一性和顺序性，DaemonSet 负责管理每个节点上的 Pod，而 Job 则可以运行一次性任务。

14.如何进行 Kubectl 命令行工具的安装和配置？

Kubectl 是 Kubernetes 命令行工具，可以用于管理 Kubernetes 集群。可以通过下载二进制文件或者使用 apt 或 yum 包管理器来安装和配置 Kubectl。

使用

kubectl get：获取资源的信息，如获取 Pod、Deployment、Service 等的列表。

示例：获取所有运行中的 Pod

kubectl get pods

kubectl describe：获取资源的详细描述信息，如获取 Pod 的详细信息。

示例：获取特定 Pod 的详细描述信息

kubectl describe pod <pod_name>

kubectl create：在集群中创建新的资源，如创建 Pod、Deployment、Service 等。

示例：创建一个 Deployment

kubectl create deployment <deployment_name> --image=<image_name>

kubectl apply：应用配置文件来创建或更新资源。

示例：应用一个 YAML 文件来创建或更新资源

kubectl apply -f <file_path>

kubectl delete：删除资源。

示例：删除一个 Deployment

kubectl delete deployment <deployment_name>

kubectl logs：获取 Pod 的日志。

示例：获取特定 Pod 的日志

kubectl logs <pod_name>

kubectl exec：在运行中的容器中执行命令。

示例：在特定 Pod 的容器中执行命令

kubectl exec -it <pod_name> -- <command>

kubectl port-forward：将集群中的一个端口转发到本地机器上。

示例：将特定 Pod 的端口转发到本地端口

kubectl port-forward <pod_name> <local_port>:<pod_port>

kubectl scale：扩展或缩小 Deployment 的副本数。

示例：将特定 Deployment 的副本数扩展到指定数量

kubectl scale deployment <deployment_name> --replicas=<replica_count>

使用 kubectl --help 或 kubectl <command> --help 来获取更详细的帮助信息。

15.分享你在使用 Kubernetes 过程中遇到的一个挑战以及你如何解决它。

k8s容器不断重启的可能原因和解决方案

资源不足：如果节点的资源（如 CPU、内存）不足以支持容器正常运行，容器可能会频繁重启。解决方案是检查节点资源使用情况，并确保节点上有足够的资源供容器使用。
配置错误：配置错误可能导致容器无法启动或崩溃，从而触发重启。解决方案是仔细检查容器的配置文件、环境变量和命令等，确保它们正确无误。
存储问题：如果容器依赖的存储卷出现问题，如挂载失败、权限问题等，容器可能无法正常运行而重启。解决方案是检查存储卷的状态，确保存储卷正常挂载，并正确配置权限。
镜像问题：容器使用的镜像可能存在问题，如权限错误、缺少依赖等，导致容器无法启动或崩溃。解决方案是确保容器镜像可用并符合要求，可以尝试使用其他版本的镜像或重新构建镜像。
网络问题：网络配置错误、端口冲突等问题可能导致容器无法正常通信，从而触发重启。解决方案是检查容器的网络配置，确保端口映射、IP 地址分配等正确配置，并避免网络冲突。
健康检查失败：容器的健康检查如果失败，将被 Kubernetes 识别为故障容器并自动重启。解决方案是检查健康检查配置，确保容器内的应用程序能够正常响应健康检查请求。
日志分析：通过查看容器的日志可以帮助定位问题，例如错误日志或异常堆栈信息。从日志中可以获取更多关于容器崩溃的线索，进而解决问题。

其它可能遇到的故障

容器崩溃（Crash）：容器在运行期间突然崩溃或异常退出。这可能由于应用程序错误、资源不足、依赖关系问题等原因引起。

解决方案：
检查容器的日志以获取详细错误信息，并根据错误日志进行故障排除。
定期监控容器的健康状态，并设置合适的资源限制和请求以避免资源不足。

网络故障：Pod 无法与其他 Pod、Service 或外部服务进行通信，可能是由于网络配置错误、网络分区、防火墙规则等原因引起。

解决方案：
检查网络配置是否正确，确保 Pod 和 Service 的地址、端口等参数正确配置。
检查网络连接是否正常，例如检查 DNS 解析是否正确、网络是否可达等。
检查网络策略和防火墙规则，确保没有被阻止访问所需的网络目标。

节点故障：Kubernetes 集群中的节点（Node）突然故障或变为不可用状态。可能是硬件故障、内存不足、网络问题等引起。

解决方案：
使用 Kubernetes 的自动节点恢复机制，例如自动重启节点或调度新的节点来替代故障节点。
设置适当的容错机制，如副本集（ReplicaSet）和自动伸缩（Autoscaling），以确保在节点故障时有足够的副本来提供服务。

无法调度 Pod：Pod 无法被调度到可用的节点上，可能是资源不足、调度策略配置错误等原因引起。

解决方案：
检查节点资源情况，确保有足够的 CPU、内存和存储资源可供使用。
调整 Pod 的资源请求和限制，以便更好地利用可用资源。
检查节点亲和性和反亲和性设置，确保 Pod 可以正确调度到合适的节点上。

存储故障：与 Kubernetes 相关的存储（如 PV、PVC、CSI 驱动等）可能出现故障，导致数据丢失、无法挂载卷等问题。

解决方案：
监控存储系统，及时发现并处理故障。
定期备份数据，并确保有可靠的恢复机制。
检查存储配置和权限设置，确保正确挂载和访问存储卷。

在应对这些意外情况时，建议使用监控工具对集群、节点、容器等进行实时监测，并设置适当的警报机制。

此外，制定备份和容灾策略也是保障系统可用性和数据安全的重要措施。

2023高薪必备：K8S面试题

容器健康检查 - 探针

Kubernetes 提供了多种方式来检查容器的健康状况，以确保 Pod 中的容器能够正常运行。以下是其中的几种方式：

运行时探针

运行时探针（Liveness Probe）：用于检测容器是否处于运行状态。如果容器未响应探针，则 Kubernetes 认为容器已经崩溃，并将重启该容器。

示例：在 Deployment YAML 文件中添加 Liveness Probe

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10

initialDelaySeconds 是指容器第一次探测（Liveness Probe、Readiness Probe 或 Startup Probe）之前的等待时间。在容器启动后的这段等待时间内，Kubernetes 将不会执行任何探测操作。
通过设置合适的 initialDelaySeconds 值，可以确保容器在启动后有足够的时间完成初始化、加载依赖项或进行其他必要的准备工作，然后再进行健康状态检查。这样可以避免在容器尚未完全启动之前就进行探测，并可能导致错误的健康状态判断。

periodSeconds 是 Kubernetes 中容器探针的一个配置参数，用于指定探测操作之间的时间间隔。
具体来说，periodSeconds 是指在一次探测操作完成后，下一次探测操作开始之前的等待时间。也就是说，Kubernetes 将按照 periodSeconds 配置的时间间隔周期性地执行容器的健康状态检查。

就绪探针

就绪探针（Readiness Probe）：用于检测容器是否已经准备好接受流量。如果容器未响应探针，则 Kubernetes 认为容器尚未准备好，并将从 Service 端点中删除该容器。

示例：在 Deployment YAML 文件中添加 Readiness Probe

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5

Kubernetes 中的就绪探针（Readiness Probe）是一种用于检测容器是否已准备好接收流量的机制。

就绪探针允许您在容器启动后，等待容器内应用程序或服务完全初始化和准备就绪之后再将流量导入容器。

就绪探针在以下情况下特别有用：

在容器启动时，需要额外的时间来完成初始化、加载配置或建立连接等操作。
在容器的应用程序或服务处理请求之前，需要确保底层依赖或资源已经可用。

就绪探针可以基于以下三种方式之一进行配置：

HTTP GET: 发送 HTTP GET 请求到容器的指定路径和端口，如果响应返回成功的状态码，则认为容器已经准备就绪。
TCP Socket: 尝试通过 TCP 连接到容器的指定端口。如果连接成功，则认为容器已经准备就绪。
Exec 命令: 在容器内执行一个自定义的命令，如果命令返回成功的退出码，则认为容器已经准备就绪。

以下是一个使用 HTTP GET 进行就绪探针配置的例子：

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5

在此示例中，就绪探针将每隔 5 秒发送一个 HTTP GET 请求到容器的 /health 路径和 8080 端口。
初始延迟为 10 秒，表示容器启动后等待 10 秒才开始进行第一次就绪探测。

如果就绪探针检测失败（即请求返回非成功的 HTTP 状态码或连接失败），

Kubernetes 将不会将流量导入该容器，直到下一次探测成功为止。

使用就绪探针可确保只有准备好接受流量的容器才会被加入服务负载均衡，

并从外部环境中暴露给其他服务或用户，以提高应用程序的稳定性和可靠性。

启动探针

启动探针（Startup Probe）：用于检测容器是否已经启动。与 Liveness Probe 不同，启动探针仅在容器启动时运行，而不会周期性地运行。

示例：在 Deployment YAML 文件中添加 Startup Probe

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app
        ports:
        - containerPort: 8080
        startupProbe:
          httpGet:
            path: /healthz
            port: 8080
          failureThreshold: 30
          periodSeconds: 10