运维面试题

1 deployment和statefulset区别

Kubernetes (k8s) 中的 Deployment 和 StatefulSet 是两种不同类型的控制器，用于管理应用的生命周期，但它们适用于不同的应用场景。以下是它们在存储、调度顺序和网络分配方面的区别：

存储

• Deployment:
  • 适用于无状态应用程序。
  • 不保证持久化存储，即如果 Pod 被删除或重新创建，它的数据不会被保留。
  • 可以通过配置 PersistentVolumeClaim (PVC) 来附加持久化存储，但是 Deployment 并不确保 Pod 的身份（例如名称）保持不变，因此即使使用了 PVC，Pod 的访问路径可能会改变。
• StatefulSet:
  • 专为有状态应用设计，如数据库集群等。
  • 确保每个 Pod 都有一个稳定的、唯一的网络标识符和持久化的存储。
  • 当 StatefulSet 中的 Pod 被删除并重新创建时，它会保留之前的存储卷，并且新 Pod 会获得相同的网络标识符和存储，从而保持其“状态”。

调度顺序

• Deployment:
  • 没有特定的调度顺序。多个副本可以同时启动或停止，这取决于滚动更新策略（RollingUpdate 或 Recreate）。
  • 如果设置了最大不可用（maxUnavailable）和最大浪涌（maxSurge），那么更新过程中的调度会遵循这些规则。
• StatefulSet:
  • 具有序列化的部署和扩展行为。这意味着 StatefulSet 的 Pod 会按照一定的顺序启动、终止或更新。
  • 对于扩容操作，新的 Pods 会按序号依次创建（例如从0开始递增）。
  • 在缩容时，Pod 也会按照逆序被删除（例如先删除编号最大的 Pod）。
  • 更新过程中，StatefulSet 默认采用 RollingUpdate 策略，但会保证更新是有序进行的。

网络分配

• Deployment:
  • Pod 的 IP 地址不是固定的。每次 Pod 被重新创建时，都会被分配一个新的 IP 地址。
  • 因此，对于无状态应用来说，这种特性通常是可接受的；但对于依赖固定网络标识的应用，则不适合。
• StatefulSet:
  • 每个 Pod 都有一个稳定的网络标识符（域名），即使 Pod 被重新创建，这个标识符也不会改变。
  • 这种稳定性对于需要互相通信的服务特别有用，比如数据库集群中的节点间通信，因为它们可以根据稳定的域名来找到彼此。

2 k8s怎么实现灰度更新，怎么切流量

1. 使用 Deployment 实现滚动更新

这是最简单的方式之一，适用于大多数无状态应用。通过调整新旧版本的副本数量，可以逐步替换旧版本的应用实例。

• 步骤:
  • 创建一个初始版本的 Deployment。
  • 当需要更新时，修改 Deployment 的镜像版本，并设置适当的 maxUnavailable 和 maxSurge 参数以控制更新的速度和影响范围。
  • Kubernetes 会根据定义的策略自动创建新的 Pod 并删除旧的 Pod，从而实现滚动更新。

2. 使用 Ingress 和 Nginx Ingress Controller 进行流量切分

• 通过设置 nginx.ingress.kubernetes.io/canary-weight 注解，可以按照百分比将流量分配给新版本的服务。
• 例如，设置为 10% 的流量将被发送到 Canary 版本，而剩下的 90% 继续流向稳定版。

3 pod探针

在 Kubernetes 中，Pod 探针（Probes）用于监控容器的健康状态，并根据探针的结果决定如何处理这些容器。Kubernetes 提供了三种类型的探针：

1. Liveness Probe（存活探针）:
   • 用来判断容器是否正在运行。如果存活探针失败，Kubernetes 将重启该容器。
   • 适用于那些能够自行恢复的应用程序；例如，一个应用可能会遇到短暂的问题，但可以自动修复。
2. Readiness Probe（就绪探针）:
   • 用来判断容器是否已经准备好为请求提供服务。如果就绪探针失败，Kubernetes 会将该 Pod 从 Service 的负载均衡池中移除，直到它再次变得“就绪”。
   • 适用于需要确保容器在其完全启动并配置好之前不接收流量的情况。
3. Startup Probe（启动探针）:
   • 用于检测应用程序是否已成功启动。只有当启动探针成功时，存活和就绪探针才会开始生效。
   • 对于启动时间较长的应用特别有用，因为它可以防止在应用尚未准备好之前进行存活或就绪检查，从而避免不必要的重启。

探针类型

每种探针都可以通过以下几种方式之一来执行健康检查：

• HTTP Get:
  • Kubernetes 发送 HTTP 请求到容器的指定路径，并检查响应的状态码。如果返回的状态码在 200 和 399 之间，则认为检查成功。
• TCP Socket:
  • Kubernetes 尝试与容器建立 TCP 连接。如果连接成功，则认为检查成功。
• Exec:
  • 在容器内执行指定的命令。如果命令退出时返回码为 0，则认为检查成功。

4 keepalived原理

Keepalived 是一种广泛使用的开源软件，主要用于实现高可用性（High Availability, HA）解决方案。它通过虚拟路由冗余协议（VRRP, Virtual Router Redundancy Protocol）来确保网络服务的连续性和可靠性。以下是 Keepalived 的工作原理和主要组件的详细介绍：

工作原理

1. VRRP 概述:
   • VRRP 是 IETF 标准化的一种协议，旨在提供一种机制，使得多个路由器可以共享一个或多个虚拟 IP 地址。当主路由器（Master）失效时，备用路由器（Backup）可以接管这些虚拟 IP 地址，从而保证网络流量的连续性。
   • VRRP 通过组播地址 224.0.0.18 和特定端口（通常是 UDP 端口 112) 来发送和接收 VRRP 报文。
2. 角色分配:
   • 在 VRRP 组中，有一台设备被选举为 Master，其余的设备作为 Backup。Master 设备负责处理所有发往虚拟 IP 地址的流量。
   • 如果 Master 设备出现故障，Backup 设备之间会进行新一轮选举，选出新的 Master。这个过程是自动完成的，不需要人工干预。
3. 优先级和状态转换:
   • 每个 VRRP 实例都有一个优先级（Priority），范围从 1 到 255，默认值是 100。优先级越高，成为 Master 的可能性越大。
   • 当 Master 设备不可用时，具有最高优先级的 Backup 设备将晋升为新的 Master。
   • 如果原来的 Master 恢复了，它的行为取决于配置：它可以立即重新成为 Master（抢占模式），或者保持 Backup 状态直到当前 Master 失效（非抢占模式）。
4. 健康检查:
   • Keepalived 支持多种健康检查方法，如 TCP、HTTP、SMTP 等，以监控后端服务器的状态。
   • 如果某个后端服务器变得不可用，Keepalived 可以将其从负载均衡池中移除，并在它恢复后重新加入。
5. 通知机制:
   • Keepalived 可以配置为在状态变化时执行自定义脚本，例如发送告警通知或执行额外的操作。

主要组件

• VRRP 模块:
  • 这是 Keepalived 的核心模块，负责管理和维护 VRRP 协议。它实现了 VRRP 的所有功能，包括选举、状态转换和通告报文的发送与接收。
• IPVS 模块:
  • IPVS（IP Virtual Server）是 Linux 内核的一部分，提供了第 4 层负载均衡能力。Keepalived 可以集成 IPVS，用于构建高度可扩展的负载均衡器。
  • IPVS 支持多种调度算法，如轮询（Round Robin）、最少连接（Least Connections）、加权轮询（Weighted Round Robin）等。
• Healthchecker 模块:
  • 健康检查器负责定期检查后端服务器的健康状况。它可以根据不同的协议和响应时间来判断服务器是否正常工作。
• 管理接口:
  • Keepalived 提供了一个简单的命令行接口（CLI）和日志记录功能，方便管理员监控和调试。

配置示例

• state MASTER 表示这台机器是 VRRP 组中的 Master。
• interface eth0 指定 VRRP 报文应该通过哪个网络接口发送。
• virtual_router_id 51 定义了 VRRP 组的唯一标识符。
• priority 100 设置了该实例的优先级。
• advert_int 1 指定了 VRRP 广播报文的发送间隔为 1 秒。
• authentication 块配置了 VRRP 报文的简单密码认证。
• virtual_ipaddress 列表包含了要接管的虚拟 IP 地址。
• vrrp_script 定义了一个名为 chk_haproxy 的健康检查脚本，用于验证 HAProxy 是否正在运行。
• track_script 块告诉 Keepalived 使用 chk_haproxy 脚本来跟踪服务的健康状态。

4 为什么要设计pod，而不是直接管理容器？

1. 多容器协作

• 共享资源:
  • Pod 允许多个容器共享相同的网络命名空间、存储卷和其他资源。这意味着它们可以相互通信，就像在同一个主机上一样，而不需要通过外部网络或服务发现机制。
  • 例如，一个应用可能需要一个主应用程序容器和一个辅助的日志收集器容器。这两个容器可以放在同一个 Pod 中，日志收集器可以直接访问主应用程序的日志文件，而无需复杂的配置。
• 协同工作:
  • 在某些情况下，多个容器需要紧密协作来完成一项任务。Pod 提供了一个环境，使得这些容器可以更容易地相互配合，如共享配置文件、临时数据等。

2. 简化管理

• 统一生命周期:
  • Pod 内的所有容器共享相同的生命周期。这意味着 Kubernetes 可以将整个 Pod 视为一个单位进行调度、扩展、更新和删除操作。这简化了集群管理和运维工作，因为管理员只需要关注 Pod 的状态，而不是每个单独的容器。
• 一致的上下文:
  • Pod 为容器提供了一致的运行环境，包括 IP 地址、DNS 名称、存储卷挂载点等。这样可以确保即使在不同的节点上运行，容器也能获得相同的行为和依赖关系。

3. 服务发现和网络通信

• 单一 IP 地址:
  • 每个 Pod 都有一个唯一的 IP 地址，这使得其他服务可以通过这个 IP 来与 Pod 内的任何容器通信。即使 Pod 内有多个容器，外部服务也只需要知道 Pod 的 IP 地址即可。
• 内部通信:
  • Pod 内的容器可以通过 localhost 或者通过环境变量直接相互通信，而不需要额外的网络配置。这种简化的内部通信方式有助于构建更紧凑和高效的分布式系统。

4. 健康检查和自我修复

• 统一探针:
  • Kubernetes 可以为 Pod 定义存活探针（Liveness Probe）和就绪探针（Readiness Probe），用于监控 Pod 内所有容器的健康状态。如果某个容器失败，Kubernetes 可以根据策略重启整个 Pod 或者只重启特定的容器。
• 自动恢复:
  • 当 Pod 内的某个容器崩溃时，Kubernetes 会尝试重启该容器。如果问题无法解决，Kubernetes 可以销毁整个 Pod 并重新创建一个新的实例，以确保应用的高可用性。

5 有什么例子是需要在容器里面运行多个进程的？

在 Kubernetes 中，容器通常是为运行单个进程而设计的，这遵循了“一个容器一个进程”的最佳实践。然而，在某些情况下，你可能会发现需要在一个容器中运行多个进程。以下是这两种情况的具体例子：

1. 辅助服务（Sidecar 模式）

• 日志收集器:
  • 在同一个 Pod 中，主应用容器负责处理业务逻辑，而另一个容器（如 Fluentd 或 Filebeat）作为 Sidecar 负责收集和转发日志。
  • 原因: 这种方式可以将日志收集与主应用分离，简化主应用的代码，同时确保日志能够被可靠地采集和传输。
• 监控代理:
  • 主应用容器运行应用程序，而另一个容器（如 Prometheus Node Exporter 或 cAdvisor）用于监控主机资源使用情况或应用性能指标。
  • 原因: 监控代理通常需要访问宿主机的文件系统或其他敏感信息，将其放在单独的容器中可以提高安全性，并且便于管理和更新。
• 数据同步工具:
  • 在数据库迁移或备份任务中，可能需要一个容器来执行主业务逻辑，另一个容器用来同步数据到远程存储或进行增量备份。
  • 原因: 数据同步操作可能较为耗时且对资源有较高要求，将其放在独立的容器中可以避免影响主应用的性能。

6 service是什么？

在 Kubernetes (k8s) 中，Service 是一个抽象层，用于定义一组逻辑上相关的 Pod 以及如何访问它们的策略。它提供了一种稳定且可靠的网络接口，使得应用程序可以在不关心具体 Pod IP 地址的情况下与这些 Pod 进行通信。Service 的主要作用是实现服务发现和负载均衡。

Service 的核心概念

1. 服务发现:
   • Service 为一组 Pod 提供了一个固定的 IP 地址和 DNS 名称，即使这些 Pod 的实际 IP 地址发生变化（例如，Pod 被重新调度或重启），客户端仍然可以通过这个固定的服务地址来访问它们。
2. 负载均衡:
   • Service 可以将流量分发到后端的多个 Pod 上，从而实现负载均衡。Kubernetes 内置的负载均衡机制可以根据不同的算法（如轮询、最少连接等）来分配请求。
3. 访问控制:
   • 通过 Service 的配置，可以限制哪些客户端能够访问特定的服务。这可以通过网络策略（Network Policies）或其他安全措施来实现。
4. 外部访问:
   • Service 不仅可以用于集群内部的服务发现，还可以配置为允许从集群外部访问服务。这对于暴露 Web 应用程序或其他需要对外提供服务的应用非常有用。

Service 的类型

Kubernetes 支持多种类型的 Service，每种类型决定了服务如何被访问：

1. ClusterIP (默认):
   • 这是最基本的服务类型，它为服务分配一个集群内部的虚拟 IP 地址（ClusterIP）。该 IP 地址只能在集群内部访问，不能从外部网络直接访问。
   • 适用于仅限于集群内部通信的服务。
2. NodePort:
   • 在每个节点上开放一个特定的端口（NodePort），并将流量转发到服务的 ClusterIP。这样，外部客户端可以通过任何节点的 IP 地址和该端口来访问服务。
   • 适用于需要从外部网络访问但不需要复杂的负载均衡的服务。
3. LoadBalancer:
   • 为服务创建一个外部负载均衡器（通常由云提供商管理），并将流量路由到服务的 NodePort 或 ClusterIP。这提供了更高级别的外部访问能力，并且支持自动扩展和高可用性。
   • 适用于需要高性能和高可用性的外部服务。
4. ExternalName:
   • 将服务映射到一个外部的 DNS 名称，而不是一组 Pod。客户端可以通过服务的名称来解析并访问外部资源。
   • 适用于需要访问外部系统而不将其直接引入集群的情况。

Service 的工作原理

• 选择器（Selector）:
  • Service 使用标签选择器（Label Selector）来确定哪些 Pod 属于该服务。只有带有匹配标签的 Pod 才会被视为该服务的后端。
  • 例如，如果你有一个 Service 定义了 app=web 的选择器，那么所有带有 app=web 标签的 Pod 都会成为该服务的后端。
• 代理模式（Proxy Mode）:
  • Kubernetes 使用 kube-proxy 来实现服务的负载均衡功能。kube-proxy 运行在每个节点上，负责维护网络规则（如 iptables 或 IPVS），以便将流量正确地路由到目标 Pod。
  • 当客户端尝试访问服务时，kube-proxy 会根据配置的策略将请求转发到适当的后端 Pod。

7 kubelet作用

kubelet 是 Kubernetes 集群中每个节点上的核心组件，负责管理该节点上的所有 Pod 和容器。它的主要职责包括：

• 创建和删除 Pod，确保它们按照预期的状态运行。
• 监控容器的健康状态，并通过探针机制确保容器的稳定性和可靠性。
• 管理资源分配，确保每个容器获得适当的资源，并防止资源争用。
• 与主控平面通信，报告节点和 Pod 的状态，并接收新的配置指令。
• 处理节点的健康检查，确保节点本身处于良好的运行状态。

通过 kubelet，Kubernetes 能够实现高度自动化和弹性的容器编排，确保应用程序在动态环境中稳定运行。

8 Scheduler作用

Kubernetes (k8s) 的调度器（Scheduler）是集群中负责将 Pod 分配到合适节点的核心组件之一。它的主要任务是根据一系列策略和规则，选择最合适的节点来运行新创建的 Pod。调度器的工作原理可以分为几个关键步骤：预选（Predicates）、优选（Priorities） 和 绑定（Binding）。此外，调度器还支持可扩展性和插件化，以便用户可以根据自己的需求自定义调度逻辑。

调度器的工作流程

1. 获取待调度的 Pod

   • 当一个新的 Pod 被创建时，它会进入 Pending 状态，并被存储在 API Server 中。
   • 调度器通过监听 API Server 的事件，获取所有处于 Pending 状态的 Pod，并将其加入调度队列。

2. 预选（Predicates）

   • 预选阶段用于过滤掉不符合条件的节点。调度器会根据一系列预选规则（也称为过滤器），筛选出能够满足 Pod 资源需求和其他约束条件的节点。

   • 常见的预选规则包括：

     • 资源充足性检查：确保节点有足够的 CPU、内存等资源来运行 Pod。
     • 节点选择器（NodeSelector）：根据 Pod 的 nodeSelector 字段，选择带有特定标签的节点。
     • 节点亲和性（Node Affinity）：根据 Pod 的 nodeAffinity 规则，选择或排除某些节点。
     • Pod 亲和性/反亲和性（Pod Affinity/Anti-Affinity）：根据其他 Pod 的标签，选择或避免与某些 Pod 运行在同一节点上。
     • 污点和容忍（Taints and Tolerations）：确保 Pod 只会被调度到具有相应容忍度的节点上。
     • 卷绑定（Volume Binding）：确保节点上有足够的持久卷可用，或者可以动态创建所需的卷。

   • 如果某个节点通过了所有预选规则，它就会进入候选节点列表；如果没有任何节点通过预选，Pod 将继续处于 Pending 状态，等待新的节点或资源可用。

3. 优选（Priorities）

   • 在预选阶段之后，调度器会从候选节点列表中选择一个最合适的节点。这个选择过程基于一系列优先级函数（Priorities），这些函数为每个候选节点打分，分数越高表示该节点越适合运行该 Pod。
   • 常见的优先级函数包括：
     • 资源利用率：优先选择资源利用率较低的节点，以实现更好的负载均衡。
     • 节点优先级：根据节点的优先级标签（如 priorityClassName），选择优先级较高的节点。
     • Pod 拓扑分布（Pod Topology Spread Constraints）：确保 Pod 在集群中的不同区域（如不同的机架、可用区）均匀分布，以提高高可用性。
     • 节点亲和性：根据节点的标签，选择更符合亲和性规则的节点。
     • Pod 亲和性/反亲和性：根据其他 Pod 的标签，选择或避免与某些 Pod 运行在同一节点上。
   • 调度器会综合考虑所有优先级函数的评分，选择得分最高的节点作为最终的目标节点。

4. 绑定（Binding）

   • 一旦确定了目标节点，调度器会向 API Server 发送绑定请求，将 Pod 绑定到该节点上。这一步骤会更新 Pod 的 spec.nodeName 字段，指定其运行的节点名称。
   • 绑定成功后，kubelet 会在该节点上启动 Pod，并将其状态从 Pending 变更为 Running。

9 创建一个pod流程

1. 用户提交 Pod 创建请求，API Server 接收并存储 Pod 对象。
2. 调度器选择合适的节点，并通过绑定操作将 Pod 分配到目标节点上。
3. kubelet 在节点上创建 Pod，准备容器环境并启动容器。
4. Pod 状态更新，API Server 记录 Pod 的状态变化。
5. 后续维护，kubelet 持续监控 Pod 的运行状态并进行必要的维护操作。

10 kube-proxy作用

kube-proxy 是 Kubernetes 集群中负责服务发现和网络通信的核心组件。它的主要作用包括：

• 服务发现：确保集群中的应用程序可以通过服务名称访问其他服务。
• 负载均衡：为每个服务提供基本的负载均衡功能，确保流量均匀分发到后端 Pod。
• 网络代理：处理进入和离开节点的流量，确保服务的请求能够正确地转发到目标 Pod。
• SNAT 和 DNAT：处理源地址转换和目标地址转换，确保流量能够正确地到达目标 Pod 并返回给客户端。
• 健康检查：定期检查后端 Pod 的健康状态，确保只有健康的 Pod 接收流量。
• 端口转发：支持 NodePort 和 LoadBalancer 类型的服务，允许外部流量通过节点的特定端口访问集群内的服务。

11 k8s内pod的端口一般多大？

• nodePort（仅适用于 NodePort 类型的 Service）：
  这是 Kubernetes 在每个节点上开放的端口，允许外部流量通过节点的 IP 地址和该端口访问 Service。
  nodePort 的默认端口范围是 30000-32767，这是 Kubernetes 为 NodePort 服务预留的端口范围。你可以通过修改 kube-apiserver 的配置来调整这个范围。

12 docker namespace和cgroup的原理

Docker 中的 Namespace 和 cgroup 原理

Docker 容器的核心功能之一是提供进程、网络、文件系统等方面的隔离，同时对资源进行限制和管理。这些功能主要依赖于 Linux 内核的两个关键技术：Namespace 和 cgroup。下面我将详细介绍这两者的原理及其在 Docker 中的应用。

---

1. Namespace（命名空间）

Docker 通过结合 Namespace 和 cgroup，实现了轻量级的容器隔离和资源管理。具体来说：

• Namespace 提供了进程、网络、文件系统等方面的隔离，确保容器之间的资源互不干扰。
• cgroup 提供了 CPU、内存、磁盘 I/O 等资源的限制和监控，确保容器不会消耗过多的系统资源。

13 502 504状态码

状态码	作用
301	永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302	临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303	查看其它地址。与301类似。使用GET和POST请求查看
304	未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。
501	服务器不支持请求的功能，无法完成请求
502	作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
503	由于超载或系统维护，服务器暂时的无法处理客户端的请求。
504	充当网关或代理的服务器，未及时从远端服务器获取请求

14 iptables

• 四表

名称	作用	链
filter表	用于过滤数据包	input forward output
nat表	用于网络地址转换，包括源地址转换（SNAT）、目的地址转换（DNAT）	output pre-routing post-routing
raw 表	用于指定哪些连接不被状态跟踪	pre-routing output
mangle 表	用于修改数据包的头部信息，例如TTL值、优先级等。	output pre-routing post-routing input forward

• 五链

名称	作用
input	负责过滤所有目标地址
forward	负责转发流经的数据包
output	处理本机地址的数据包
pre-routing	在数据包到达防火墙时，进行路由判断之前的执行规则
post-routing	在数据包离开防火墙时进行路由判断之后的执行规则

15 存储

volumn

• HostPath:将节点上的文件或目录挂载到 Pod 上，此时该目录会变成持久化存储目录，即使 Pod 被删除后重启，也可以重新加载到该目录，该目录下的文件不会丢失 。
• EmptyDir 主要用于一个 Pod 中不同的 Container 共享数据使用的，由于只是在 Pod 内部使用，因此与其他 volume 比较大的区别是，当 Pod 如果被删除了，那么 emptyDir 也会被删除。

nfs
nfs 卷能将 NFS (网络文件系统) 挂载到你的 Pod 中。 不像 emptyDir 那样会在删除 Pod 的同时也会被删除，nfs 卷的内容在删除 Pod 时会被保存，卷只是被卸载。 这意味着 nfs 卷可以被预先填充数据，并且这些数据可以在 Pod 之间共享。

PV
持久卷（PersistentVolume，PV） 是集群中的一块存储，可以由管理员事先制备， 或者使用存储类（Storage Class）来动态制备。 持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样， 也是使用卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。 此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。

PVC
持久卷申领（PersistentVolumeClaim，PVC） 表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源，而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源（CPU 和内存）；同样 PVC 申领也可以请求特定的大小和访问模式 （例如，可以要求 PV 卷能够以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany 模式之一来挂载，参见访问模式）。

StorageClass
通过 StorageClass 可以实现仅仅配置 PVC，然后交由 StorageClass 根据 PVC 的需求动态创建 PV。

16 k8s apply 一个3副本的yaml 具体流程，哪些组件参与了哪些工作

1. 用户：使用 kubectl apply 命令。
2. kubectl 客户端：解析 YAML 文件并发送 API 请求。
3. API 服务器：接收请求，验证、授权并存储数据到 etcd。
4. etcd：存储资源状态。
5. 控制器管理器：包含 Deployment 控制器，监视 Deployment 资源并创建或更新 ReplicaSets。
6. ReplicaSet 控制器：监视 ReplicaSet 资源并创建或更新 Pods。
7. 调度器：决定将 Pods 分配到哪个节点上。
8. Kubelet：管理节点上的 Pods，创建和启动容器。
9. 容器运行时：实际创建和管理容器。

17 client-go

名称	作用	使用场景
RestClient	RestClient 是一个低级别的 HTTP 客户端，它提供了对 Kubernetes API 进行 RESTful 调用的基础功能。它是其他更高级别客户端（如 clientset）的基础构建块。	低级别的 HTTP 客户端，适合需要高度定制化的场景。
ClientSet	高级别的 Kubernetes API 客户端，它封装了对 Kubernetes API 的访问，提供了类型安全的方法来操作 Kubernetes 资源（如 Pods、Services、Deployments 等）。	高级别的类型安全客户端，适合操作标准的 Kubernetes 资源。
DynamicClient	动态类型的 Kubernetes API 客户端，它允许你操作任意的 Kubernetes 资源，而不需要事先知道这些资源的具体类型。	动态类型的客户端，适合操作自定义资源或多种不同类型的资源。
DiscoveryClient	用于发现和获取 Kubernetes API 的信息，包括可用的 API 组、版本和资源类型。	用于发现和查询 Kubernetes API 的信息，适合需要动态适应 API 变化的场景。

18 informer

Kubernetes Informer 的工作流程

Kubernetes 的 Informer 是一种用于监听和缓存 Kubernetes API 资源（如 Pod、Deployment、Service 等）变化的机制。它通过与 Reflector 和 DeltaFIFO 队列协同工作，提供了高效的资源同步和事件处理能力。Informer 是 Kubernetes 控制器（Controller）开发中常用的工具，广泛应用于自定义控制器、Operator 和其他需要实时响应资源变化的应用场景。

1. Informer 的核心组件

Informer 的工作流程涉及多个核心组件，每个组件都有特定的职责：

• Reflector：负责从 Kubernetes API Server 拉取资源，并将资源对象存储到本地缓存中。它还会监听资源的变化（创建、更新、删除），并将这些变化推送到 DeltaFIFO 队列。
• DeltaFIFO：一个去重的 FIFO（先进先出）队列，用于存储资源的变化事件（称为 “deltas”）。每个 delta 包含资源对象的状态变化（如创建、更新、删除）。DeltaFIFO 确保每个资源对象的事件按顺序处理，并且不会重复处理相同的事件。
• Indexer：一个本地缓存，用于存储从 API Server 拉取的资源对象。Indexer 提供了快速的读取和查询能力，支持基于标签、字段等条件进行资源查找。
• ResourceEventHandler：负责处理从 DeltaFIFO 队列中取出的事件。它通常包含三个回调函数：
  • AddFunc：当资源被创建时调用。
  • UpdateFunc：当资源被更新时调用。
  • DeleteFunc：当资源被删除时调用。

7. 从 DeltaFIFO 队列中取出事件：

   • Informer 会定期从 DeltaFIFO 队列中取出 delta 事件，并根据事件类型（创建、更新、删除）调用相应的 ResourceEventHandler 回调函数。

8. 更新 Indexer 缓存：

   • 在调用 ResourceEventHandler 回调函数之前，Informer 会根据事件类型更新 Indexer 缓存中的资源对象。例如，当收到 Add 事件时，Informer 会将新的资源对象添加到 Indexer 中；当收到 Delete 事件时，Informer 会从 Indexer 中删除对应的资源对象。

9. 触发用户定义的回调函数：

   • Informer 会根据事件类型调用用户定义的 ResourceEventHandler 回调函数。例如，当收到 Add 事件时，Informer 会调用 AddFunc 回调函数；当收到 Update 事件时，Informer 会调用 UpdateFunc 回调函数；当收到 Delete 事件时，Informer 会调用 DeleteFunc 回调函数。

---

19 calico 网络

与host-gw模式几乎一样
核心：也是把宿主机当成一台路由器去用

• 与host-gw的区别:

  • host-gw模式下路由信息的维护是有flanneld进程维护(状态存于与etcd中)
  • BGP模式是由BGP协议来自动维护，不需要中心化的数据库。所谓BGP，就是大规模网络中实现节点路由信息共享的一种协议
  • BGP模式不会再宿主主机上创建cni0网桥

• 一个完整的bgp网络拓扑如下，主要由三个部分组成:
  1.Calico 的 CNI插件(注意是插件，不是cni0网桥哈)。这是 Calico 与 K8s 对接的部分。
  2.Felix:是一个守护程序(在k8s中以DeaemonSe部署)，以agent形式运行在宿主机上，负责在宿主机上插入路由规则(即:写入Linux 内核的 FIB 转发信息库)，以及维护上alico 所需的网络设备等工作。
  3.BIRD。BGP 的客户端，作用是读取Felix编写到内核中的路由信息，并将路由信息分发到集群中的其他节点。

20 tcp/ip四层模型对应的协议

21 如何查找目标目录下的文件大小>20mb的文件 修改时间在五分钟内的文件

find /path/to/directory -type f -size +20M -mmin -5

22 grep、egrep、fgrep

grep、fgrep 和 egrep 的对比

为了更清晰地对比 grep、fgrep 和 egrep，我们可以使用表格的形式来展示它们的主要区别和特点。这三种工具都用于文本搜索，但它们在正则表达式的支持、性能和使用场景上有所不同。

特性/命令	grep	fgrep (或 grep -F)	egrep (或 grep -E)
默认模式	使用 基本正则表达式 (BRE)	使用 固定字符串匹配	使用 扩展正则表达式 (ERE)
正则表达式支持	支持基本正则表达式（如 .、*、^、$）	不支持正则表达式，仅支持固定字符串匹配	支持扩展正则表达式（如 +、?、`
性能	对于简单的模式，性能与 fgrep 类似	通常比 grep 和 egrep 更快，因为它不解析正则表达式	对于复杂的模式，性能可能稍慢，因为需要解析 ERE
常用选项	-E（等同于 egrep）、-F（等同于 fgrep）	-F 或 --fixed-strings	-E 或 --extended-regexp
别名	无	fgrep 是 grep -F 的别名	egrep 是 grep -E 的别名
适用场景	适合需要使用 基本正则表达式 的场景	适合需要进行 精确字符串匹配 的场景	适合需要使用 复杂正则表达式 的场景
示例	grep "hello\." file.txt	fgrep "hello." file.txt	`egrep "hello
是否支持多行匹配	不直接支持多行匹配，但可以通过 -P 选项启用 PCRE	不支持多行匹配	不直接支持多行匹配，但可以通过 -P 选项启用 PCRE
是否支持 Perl 兼容正则表达式 (PCRE)	需要使用 -P 选项	不支持 PCRE	需要使用 -P 选项

23 LVS

• 四层负载均衡：LVS 工作在 OSI 模型的第四层（传输层），主要处理 TCP 和 UDP 协议的流量。它不解析应用层协议，因此具有较低的延迟和较高的性能。
• 多种调度算法：LVS 支持多种负载均衡算法，如轮询（Round Robin）、最少连接（Least Connections）、加权轮询（Weighted Round Robin）、加权最少连接（Weighted Least Connections）等。
• 三种工作模式：
  • DR（Direct Routing）模式：LVS 将请求直接路由到后端服务器，后端服务器可以直接响应客户端，而不需要经过 LVS。这种方式对网络拓扑要求较高，但性能最好。
  • TUN（Tunneling）模式：LVS 通过隧道将请求封装后发送到后端服务器，后端服务器解封装后再处理请求。这种方式对网络拓扑要求较低，适合跨数据中心的场景。
  • NAT（Network Address Translation）模式：LVS 通过 NAT 将客户端请求转发到后端服务器，后端服务器的响应必须经过 LVS 返回给客户端。这种方式对网络拓扑要求最低，但性能相对较差。
• 高可用性：LVS 可以与 Keepalived 结合使用，提供主备切换功能，确保负载均衡器的高可用性。

24 Lnux 中文件描述符最大数量是多少

cat /proc/sys/fs/file-max

1048576

25 输出IO占用最多的磁盘号 (iostat )

ostat 是一个用于监控系统输入/输出设备负载的工具，它可以显示 CPU 使用率、磁盘 I/O 活动和传输速率等信息。

 -c：显示 CPU 使用情况。-d：显示设备（磁盘）使用情况。-k：以 KiB 为单位

26 linux一般命令

• top动态实时显示系统中各个进程资源占用状况的工具。
• ps获取到进程的各种信息，如PID、父PID、用户ID、组ID、内存和CPU使用率等。
• netstat用于显示网络连接、路由表、接口统计等网络相关信息。
• free 命令用来查看系统内存使用情况

26 netstat常用参数

netstat（Network Statistics）是一个用于显示网络连接、路由表、接口统计信息、伪装连接和多播成员的命令行工具。它可以帮助你监控系统的网络状态，查看当前的网络连接、监听端口、路由信息等。

选项	描述
-a	显示所有连接和侦听端口（包括 TCP 和 UDP）。
-t	仅显示 TCP 连接。
-u	仅显示 UDP 连接。
-n	以数字形式显示地址和端口号，而不是解析为名称（避免 DNS 查询）。
-l	仅显示侦听状态的端口（即正在等待连接的服务器端口）。
-p	显示与每个连接关联的进程 ID (PID) 和程序名称。
-r	显示内核路由表。
-i	显示网络接口的统计信息。
-s	显示每个协议的统计信息（如 TCP、UDP、ICMP 等）。
-c	每隔一秒更新一次输出，类似于 watch 命令。
-e	显示扩展信息，如用户 ID 和接口索引。
-A <地址族>	限制显示的地址族（如 inet 表示 IPv4，inet6 表示 IPv6）。

27 time_wait过多

2.1 短生命周期的连接频繁建立和关闭

如果你的应用程序频繁建立和关闭短生命周期的连接（例如，HTTP 请求、短连接的数据库查询等），那么每个连接关闭后都会进入 TIME_WAIT 状态。随着时间的推移，大量的 TIME_WAIT 连接会累积，占用系统的文件描述符和内存资源。

2.2 客户端主动关闭连接

当客户端主动关闭连接时，客户端会进入 TIME_WAIT 状态。如果你的应用程序中有大量的客户端频繁关闭连接，那么这些客户端会积累大量的 TIME_WAIT 状态。

2.3 不合理的超时设置

默认情况下，TIME_WAIT 状态的持续时间为 2MSL（120 秒）。如果这个时间过长，尤其是在高并发的环境中，可能会导致 TIME_WAIT 状态的快速积累。虽然 120 秒是一个保守的值，但在某些情况下，你可以根据网络环境适当缩短这个时间。

2.4 服务器资源不足

如果服务器的文件描述符数量或内存资源有限，大量的 TIME_WAIT 状态可能会导致资源耗尽，进而影响新连接的建立。你可以通过调整系统的文件描述符限制来缓解这个问题。
TIME_WAIT 状态是 TCP 连接终止过程中的一种正常状态，表示连接已经完成四次握手的关闭过程，但仍然保持一段时间以确保所有数据包都已正确传输和接收。过多的 TIME_WAIT 状态可能会导致系统资源耗尽，影响新连接的建立。以下是 TIME_WAIT 状态过多产生的原因及解决方法。

1. TIME_WAIT 状态的产生机制

当一个 TCP 连接被主动关闭时，发起关闭的一方会进入 TIME_WAIT 状态。这是因为在连接关闭后，网络上可能还有未到达的数据包（如延迟的 ACK 或重传的 FIN），因此系统需要等待一段时间（通常为 2 倍的最大段生存时间，即 2MSL）以确保这些数据包不会被错误地交付给新的连接。

• 2MSL：最大段生存时间（Maximum Segment Lifetime）是指一个 TCP 数据包在网络中可以存活的最大时间。在 Linux 系统中，默认的 MSL 是 60 秒，因此 TIME_WAIT 状态的持续时间为 120 秒。

• 为什么需要 TIME_WAIT？：TIME_WAIT 状态的存在是为了防止旧连接的延迟数据包与新连接的数据包混淆。如果一个新的连接使用了与旧连接相同的源 IP、目的 IP、源端口和目的端口，那么旧连接的延迟数据包可能会被误认为是新连接的一部分，导致数据混乱。

2. TIME_WAIT 状态过多的原因

2.1 短生命周期的连接频繁建立和关闭

如果你的应用程序频繁建立和关闭短生命周期的连接（例如，HTTP 请求、短连接的数据库查询等），那么每个连接关闭后都会进入 TIME_WAIT 状态。随着时间的推移，大量的 TIME_WAIT 连接会累积，占用系统的文件描述符和内存资源。

示例场景：

• Web 服务器：对于高并发的 Web 服务器，尤其是使用短连接的 HTTP/1.1 协议时，每次请求都会建立一个新的 TCP 连接，请求完成后立即关闭连接，导致大量 TIME_WAIT 状态的连接。
• 数据库客户端：如果数据库客户端频繁地打开和关闭连接，而不是使用连接池，也会导致 TIME_WAIT 状态的积累。

2.2 客户端主动关闭连接

当客户端主动关闭连接时，客户端会进入 TIME_WAIT 状态。如果你的应用程序中有大量的客户端频繁关闭连接，那么这些客户端会积累大量的 TIME_WAIT 状态。

2.3 不合理的超时设置

默认情况下，TIME_WAIT 状态的持续时间为 2MSL（120 秒）。如果这个时间过长，尤其是在高并发的环境中，可能会导致 TIME_WAIT 状态的快速积累。虽然 120 秒是一个保守的值，但在某些情况下，你可以根据网络环境适当缩短这个时间。

2.4 服务器资源不足

如果服务器的文件描述符数量或内存资源有限，大量的 TIME_WAIT 状态可能会导致资源耗尽，进而影响新连接的建立。你可以通过调整系统的文件描述符限制来缓解这个问题。

_WAIT` 状态会导致系统资源紧张，进而影响整体性能，尤其是在高负载的情况下。

28. 解决 TIME_WAIT 状态过多的方法

• 方式一：net.ipv4.tcp_tw_reuse 和 tcp_timestamps
  如下的 Linux 内核参数开启后，则可以复用处于 TIME_WAIT 的 socket 为新的连接所用。
• 方式二：net.ipv4.tcp_max_tw_buckets
  这个值默认为 18000，当系统中处于 TIME WAIT 的连接一旦超过这个值时，系统就会将后面的TIME WAIT 连接状态重置，这个方法比较暴力。

29 linux中查看文本文件的某个区间行

sed -n 'START,ENDp' filename
awk 'NR>=START && NR<=END' filename

30 正则表达式匹配ip地址

^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$

31 mysql主从复制

主库服务（Master）：当在主库服务执行数据变更操作时（增、删、改），将操作命令记录到binlog二进制文件中。
从库服务（Slave）：从库服务向主库服务发起请求来复制变更的数据，主库服务通过一个binglog dump线程将binlog文件数据发送到从库服务；从库服务通过一个 I/O 线程将接收到的数据写入relaylog二进制文件，最后从库服务将relaylog的数据重放（Replay）完成数据同步。

32 孤儿进程 僵尸进程

• 孤儿进程
  孤儿进程是指父进程结束或终止之后，其子进程仍然继续运行的进程。这些子进程没有了父进程，因此被称为孤儿进程。在Unix和Linux系统中，孤儿进程会被init进程（进程号为1）接管。init进程会定期执行wait()系统调用来清理这些孤儿进程，释放它们占用的资源。因此，孤儿进程通常不会对系统造成危害。

• 僵尸进程
  僵尸进程是指子进程已经执行完毕并退出，但其父进程尚未通过wait()或waitpid()系统调用来获取子进程的终止状态。这时，子进程的进程描述符和部分资源仍然保留在系统中。僵尸进程占用的资源虽然不多，但它们会占用进程号，而系统可用的进程号是有限的。如果大量僵尸进程产生，可能会导致系统无法创建新的进程，从而影响系统性能。

33 排序算法

34 fork了子进程写入文件会对父进程发生变化吗

在 Linux 系统中，fork() 系统调用用于创建一个新进程（子进程），该子进程是调用 fork() 的进程（父进程）的一个副本。子进程继承了父进程的大部分属性，包括文件描述符、环境变量、内存映像等。然而，父子进程之间的资源是独立的，某些操作在子进程中执行时不会影响父进程。

35 snat和dnat

SNAT：修改数据包的 源 IP 地址。通常用于内部网络中的主机访问外部网络时，将私有 IP 地址替换为公共 IP 地址。
DNAT：修改数据包的 目标 IP 地址。通常用于外部网络中的主机访问内部网络中的服务时，将外部 IP 地址替换为内部服务的 IP 地址。

36 prometheus 组件

• Prometheus Server
  负责实现对监控数据的获取，存储以及查询。
• Exporters
  Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server
• AlertManager
  如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由AlertManager进行管理。

37 prometheus Metric监控类型

• Counter：只增不减的计数器
  例如我们可以在应用程序中记录某些事件发生的次数，通过以时序的形式存储这些数据，我们可以轻松的了解该事件产生速率的变化。
• Gauge：可增可减的仪表盘
  node_memory_MemFree（主机当前空闲的内容大小）、node_memory_MemAvailable（可用内存大小）都是Gauge类型的监控指标。
• Histogram
• Summary
  某些情况下，你可以同时使用 Histogram 和 Summary 来满足不同的需求。例如，你可以使用 Histogram 来监控请求延迟的分布情况，并使用 Summary 来计算特定的百分位数（如 p99）。