个人技术分享

k8s面试29连问

一、容器和虚拟化之间的区别

1、由于docker不需要虚拟管理程序和虚拟机操作系统，运行的只是应用，所以占用资源少。电脑同时开几个虚拟机就跑不动了。

二、k8s和docker的关系

docker主要是通过dockerfile来生产镜像，而k8s 用于关联和编排在多个主机上运行的容器

三、kube-proxy ipvs和 iptables的异同

1、kube-proxy默认是iptables，因为系统们自带这个，ipvs就不一定自带。但是ipvs性能好很多，特别是容器特别多的时候
Netfilter 是一个在 Linux 操作系统上实现网络包过滤和处理的框架。它允许用户空间程序拦截、修改或丢弃进出网络接口的数据包。Netfilter 的核心组件是 iptables，它是一个命令行工具和内核模块，用于配置 Netfilter 规则。iptables 允许管理员定义各种规则，以确定如何处理不同类型的网络流量。

2、相同在于都基于netfilter转发
iptables是为防火墙而设计的管理工具
ipvs专门用于高性能LB集群-LVS

LVS（Linux Virtual Server）是一个用于构建高可用性、高性能和可伸缩性的 Linux 负载均衡解决方案。它允许将网络流量分发到多个后端服务器上，从而提高系统的可用性和性能。LVS 在 Linux 内核中实现，提供了几种负载均衡算法和调度器来分发流量。

举例来说，假设你有一个网络应用，它需要处理大量的 HTTP 请求。为了确保应用的高可用性和性能，你可以使用 LVS 来构建一个负载均衡集群。你可以将 LVS 配置为监听进入的 HTTP 请求，并根据一定的算法将这些请求分发给后端的多个 web 服务器。

例如，你可以使用 LVS 中的最常用的负载均衡算法之一：Round Robin（轮询）。在这种情况下，LVS 将按照轮询的方式将每个新的 HTTP 请求分发给下一个后端服务器。这样一来，所有的后端服务器都会接收到大致相等数量的请求，从而实现负载均衡。

另外，LVS 还支持其他的负载均衡算法，如 Least Connections（最少连接）、Weighted Round Robin（加权轮询）和 Source Hashing（源地址哈希）等。这些算法可以根据不同的需求和场景进行选择和配置，以实现更精细化的流量分发。

3、iptables

  1. 优点：灵活，添加规则立即生效。
    可以根据tcp不同阶段进行控制

iptables 可以根据 TCP 协议中不同的阶段（如连接建立阶段、数据传输阶段和连接关闭阶段）来控制网络流量。这意味着你可以在不同的 TCP 阶段上实施不同的规则，以实现特定的网络行为。

举例说明：

  1. 连接建立阶段：在 TCP 连接建立时，你可以使用 iptables 来控制哪些连接可以被接受，哪些应该被拒绝。例如，你可以允许特定 IP 地址范围的连接进入你的服务器：
iptables -A INPUT -p tcp --syn -s 192.168.1.0/24 -j ACCEPT
  1. 数据传输阶段：在 TCP 连接建立之后，数据开始传输时，你可以使用 iptables 来控制数据包的转发、修改或丢弃。例如，你可以允许特定端口的数据流通过：
iptables -A FORWARD -p tcp --dport 80 -j ACCEPT
  1. 连接关闭阶段：在 TCP 连接关闭时，你可以清理相关的连接跟踪信息，以确保网络资源的释放。我们想要在连接关闭阶段做一些控制，特别是当收到 TCP 的复位（RST）标志时。TCP 复位标志用于强制关闭连接，它通常在网络通信出现问题或者主动关闭连接时使用
    例如，你可以在连接关闭时清除相关的连接跟踪信息：
iptables -A OUTPUT -p tcp --tcp-flags RST RST -j DROP
  1. 缺点：表规则太多时，响应变慢，线性延迟。因为它是自上而下执行的

4、ipvs
1）优点：支持哈希，转发效率高, 调度算法丰富

假设我们有一个网络应用，它提供了用户登录服务。为了实现负载均衡，我们使用 IPVS 将登录请求分发到多个后端服务器上。
现在，我们可以使用哈希算法基于客户端 IP 地址来分发请求。这意味着相同的客户端 IP 地址将始终被映射到同一台后端服务器上。这样做的好处是，如果同一个用户多次登录，他们的请求将始终被发送到同一台服务器上，从而提高了缓存的利用率和请求处理的效率。
因此，IPVS 支持哈希算法，通过哈希算法进行转发可以提高转发效率，并且可以根据不同的需求选择不同的哈希算法，例如基于源 IP 地址、目标 IP 地址、源端口、目标端口等。

2）缺点。老旧内核不支持。升级下内核到最少5.0

四、kube-proxy如何切换 ipvs

iptables是线性，从上到下执行，容器越多，它越慢。采用的是轮询，但是ipvs能检测出来哪个节点down了，把它移除掉，好了之后，再添加回来
启动ipvs，kube-proxy切换到ipvs负载模式，删除旧的kube-proxy的pod

五、蓝绿发布

只有它用于测试环境，其他金丝雀，灰度，滚动啥的发布都是交互场景了，特点是升级，回退切换速度非常快
不足：全量切换，不能控制百分之几的流量到哪个
过程：
就是运行蓝绿的yaml，同时有v1，v2两个pod【镜像内容和version不同】，通过edit service，把seletor的version改成v2,然后就切换过来了
其实不止两个版本，5个版本都能切换

六、静态pod

由kubelet创建
静态pod是把yaml放到 /etc/kubernetes/manifests/ 这里，就会自动产生pod. 只有删除掉yaml，pod才能消失
静态 Pod 的 YAML 文件放在哪个节点上，只有那个节点会运行该 Pod

七、k8s持久化

emptydir 临时存储
hostpath 挂载宿主机目录
pv 有很多种形式 nfs gfs ceph

八、Dockerfile中 copy和add 的区别

copy 把宿主机文件或目录复制到容器内
add 把宿主机文件或目录复制到容器内 并且 还可以自动解压缩压缩文件（如 .tar, .tar.gz, .tgz, .bzip2, .bz2, .xz, .tar.xz, .zip 等格式），并且可以指定远程 URL 进行下载和添加到容器中

三十、k8s的备份和还原。配合ceph

将所有有状态服务的存储数据存储在另一个地方是一种备份数据的方法，但仅仅删除 Kubernetes 并重新安装并不能完全恢复之前的服务状态。下面是一些你需要考虑的因素：

  1. 配置数据备份：除了有状态服务的存储数据外，你还需要备份配置数据，如 ConfigMap 和 Secrets。这些数据包含了应用程序配置和敏感信息，对于完全恢复服务非常重要。

  2. 集群配置备份：Kubernetes 集群的配置信息，例如节点配置、网络配置等，也需要备份。如果你重装 Kubernetes，你需要确保在重装之前保存这些信息，以便在新的 Kubernetes 集群中恢复。

  3. 应用程序镜像和部署描述：如果你的服务依赖于特定的容器镜像和部署描述（如 Deployment、StatefulSet），你需要确保这些镜像和描述也能被恢复或者重新创建。

  4. 数据迁移和恢复：在重新安装 Kubernetes 后，你需要将之前备份的数据和配置重新导入到新的 Kubernetes 集群中。这可能需要一些手动操作或者使用自动化工具来帮助你完成。

总之，虽然备份有状态服务的存储数据是恢复服务的重要一部分，但你还需要备份和恢复其他关键数据和配置信息才能确保完全的恢复。因此，在执行这样的操作之前，请确保你有一个全面的备份和恢复计划，并测试这个计划以确保它可以按预期工作。

31、keepalived和 haproxy

apiserver负载均衡： 在Kubernetes集群中，HAProxy可以部署在apiserver前面，作为负载均衡器使用，负责将来自客户端（如kubectl命令行工具或其它组件）的请求均匀地分发到多个apiserver实例上，提高系统的整体吞吐量和响应速度。

在构建Kubernetes多Master节点的高可用集群时，Keepalived可以用于管理kube-apiserver的VIP。如果有任何一个Master节点故障，Keepalived会自动将VIP切换到另一个健康的Master节点，确保API服务不间断。

32、静态pod

kubeshpere自带etcd，静态pod的形式
静态 Pod 是 Kubernetes 中一种特殊的 Pod 实现方式，与通过控制器（如 Deployment、StatefulSet 或 DaemonSet）动态管理的 Pod 不同，静态 Pod 是直接由节点上的 kubelet 进程管理的，并且仅存在于创建它的那个节点上。这意味着静态 Pod 不是由 Kubernetes API 服务器管理的，你不能通过 API 对它们进行修改、删除或查询操作，也无法与副本控制器（ReplicationController）或其他高级资源对象相关联。

静态 Pod 的用武之地包括：

  1. 系统服务或基础设施组件：

    • 在一些场景下，你可能希望在每个节点上运行一些基础服务，如监控代理（Prometheus Node Exporter）、日志收集器（Fluentd）或节点级别的监控工具，这些服务不需要水平扩展，也不需要复杂的管理逻辑，静态 Pod 很适合这类应用。

  2. 测试和开发环境：

    • 在本地开发或测试环境中，可能不需要复杂的部署管理流程，直接通过静态 Pod 快速部署应用可以简化开发流程，加快迭代速度。

  3. 高度定制化的应用部署：

    • 当应用有非常特定的部署需求，不适用于标准的控制器模式时，静态 Pod 提供了一种灵活的部署方式。例如，某些应用可能需要直接与宿主机系统服务紧密集成，或者有严格的节点亲和性需求。

举例说明：

假设你在一个 Kubernetes 集群中，想要确保每个节点上都运行一个日志收集代理，而且这个代理不需要根据负载自动扩缩容，也不需要复杂的更新策略。这时，就可以使用静态 Pod 来部署这个日志收集代理。

操作步骤如下：

  1. 准备 Pod 配置文件：首先，在每个节点的 /etc/kubernetes/manifests/ 目录下创建一个 YAML 文件，定义日志收集代理的 Pod 规格，包括容器镜像、端口映射、资源请求等信息。

  2. kubelet 自动创建 Pod：当 kubelet 在节点上启动时，它会自动检查这个目录下的所有文件，并根据这些文件的定义创建对应的静态 Pod。

  3. 监控与管理：由于静态 Pod 是由 kubelet 直接管理的，如果 Pod 出现故障，kubelet 会自动尝试重启它。但是，要查看 Pod 的状态或对其进行修改，就需要直接操作节点上的配置文件。

通过这种方式，每个节点上都会有一个独立的日志收集代理运行，且其生命周期直接与节点绑定，无需额外的管理开销。