[口试] 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 文件来定义你的应用程序。下面是一个示例文件

1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4.   name: my-app
5. spec:
6.   replicas: 3                     # 定义副本数
7.   selector:
8.     matchLabels:
9.       app: my-app
10.   template:
11.     metadata:
12.       labels:
13.         app: my-app
14.     spec:
15.       containers:
16.       - name: my-app
17.         image: my-app:latest       # 容器镜像
18.         ports:
19.         - containerPort: 8080     # 容器监听的端口

复制代码

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

1. kubectl apply -f deployment.yaml

复制代码

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

1. kubectl get deployments
3. kubectl get pods

复制代码

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

1.     spec:
2.       containers:
3.       - name: my-app
4.         image: my-app: new-version   # 更新为新的镜像版本
5.         ports:
6.         - containerPort: 8080

复制代码

然后再次实行 kubectl apply 命令。

1. kubectl apply -f deployment.yaml

复制代码

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

1. kubectl rollout status deployment/my-app

复制代码

回滚到旧版本（可选）：假如滚动更新出现题目，可以回滚到旧版本。使用 kubectl rollout undo 命令举行回滚操纵。

1. 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

1. kubectl get pods

复制代码

kubectl describe：获取资源的具体描述信息，如获取 Pod 的具体信息。
示例：获取特定 Pod 的具体描述信息

1. kubectl describe pod <pod_name>

复制代码

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

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

复制代码

kubectl apply：应用配置文件来创建或更新资源。
示例：应用一个 YAML 文件来创建或更新资源

1. kubectl apply -f <file_path>

复制代码

kubectl delete：删除资源。
示例：删除一个 Deployment

1. kubectl delete deployment <deployment_name>

复制代码

kubectl logs：获取 Pod 的日志。
示例：获取特定 Pod 的日志

1. kubectl logs <pod_name>

复制代码

kubectl exec：在运行中的容器中实行命令。
示例：在特定 Pod 的容器中实行命令

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

复制代码

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

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

复制代码

kubectl scale：扩展或缩小 Deployment 的副本数。
示例：将特定 Deployment 的副本数扩展到指定命量

1. 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

1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4.   name: my-app
5. spec:
6.   replicas: 3
7.   selector:
8.     matchLabels:
9.       app: my-app
10.   template:
11.     metadata:
12.       labels:
13.         app: my-app
14.     spec:
15.       containers:
16.       - name: my-app
17.         image: my-app
18.         ports:
19.         - containerPort: 8080
20.         livenessProbe:
21.           httpGet:
22.             path: /
23.             port: 8080
24.           initialDelaySeconds: 30
25.           periodSeconds: 10

复制代码

  initialDelaySeconds 是指容器第一次探测（Liveness Probe、Readiness Probe 或 Startup Probe）之前的等候时间。在容器启动后的这段等候时间内，Kubernetes 将不会实行任何探测操纵。
通过设置合适的 initialDelaySeconds 值，可以确保容器在启动后有足够的时间完成初始化、加载依靠项或举行其他必要的预备工作，然后再举行健康状态查抄。如允许以制止在容器尚未完全启动之前就举行探测，并可能导致错误的健康状态判断。
    periodSeconds 是 Kubernetes 中容器探针的一个配置参数，用于指定探测操纵之间的时间隔断。
具体来说，periodSeconds 是指在一次探测操纵完成后，下一次探测操纵开始之前的等候时间。也就是说，Kubernetes 将按照 periodSeconds 配置的时间隔断周期性地实行容器的健康状态查抄。
  就绪探针

就绪探针（Readiness Probe）：用于检测容器是否已经预备好接受流量。假如容器未响应探针，则 Kubernetes 认为容器尚未预备好，并将从 Service 端点中删除该容器。
示例：在 Deployment YAML 文件中添加 Readiness Probe

1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4.   name: my-app
5. spec:
6.   replicas: 3
7.   selector:
8.     matchLabels:
9.       app: my-app
10.   template:
11.     metadata:
12.       labels:
13.         app: my-app
14.     spec:
15.       containers:
16.       - name: my-app
17.         image: my-app
18.         ports:
19.         - containerPort: 8080
20.         readinessProbe:
21.           httpGet:
22.             path: /healthz
23.             port: 8080
24.           initialDelaySeconds: 10
25.           periodSeconds: 5

复制代码

Kubernetes 中的就绪探针（Readiness Probe）是一种用于检测容器是否已预备好接收流量的机制。
就绪探针答应您在容器启动后，等候容器内应用程序或服务完全初始化和预备就绪之后再将流量导入容器。
就绪探针在以下情况下特别有用：

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

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

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

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

1. readinessProbe:
2.   httpGet:
3.     path: /health
4.     port: 8080
5.   initialDelaySeconds: 10
6.   periodSeconds: 5

复制代码

在此示例中，就绪探针将每隔 5 秒发送一个 HTTP GET 请求到容器的 /health 路径和 8080 端口。
初始延迟为 10 秒，表示容器启动后等候 10 秒才开始举行第一次就绪探测。
假如就绪探针检测失败（即请求返回非乐成的 HTTP 状态码或毗连失败），
Kubernetes 将不会将流量导入该容器，直到下一次探测乐成为止。
使用就绪探针可确保只有预备好接受流量的容器才会被加入服务负载均衡，
并从外部环境中袒露给其他服务或用户，以进步应用程序的稳定性和可靠性。
启动探针

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

1. apiVersion: apps/v1
2. kind: Deployment
3. metadata:
4.   name: my-app
5. spec:
6.   replicas: 3
7.   selector:
8.     matchLabels:
9.       app: my-app
10.   template:
11.     metadata:
12.       labels:
13.         app: my-app
14.     spec:
15.       containers:
16.       - name: my-app
17.         image: my-app
18.         ports:
19.         - containerPort: 8080
20.         startupProbe:
21.           httpGet:
22.             path: /healthz
23.             port: 8080
24.           failureThreshold: 30
25.           periodSeconds: 10

复制代码

使用这些探针可以有用地查抄容器的健康状态，并主动重启或移除不正常的容器。
在计划容器镜像时，发起添加得当的探针来确保镜像在 Kubernetes 集群中的稳定运行。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。