k8s面试题

最新推荐文章于 2025-06-15 20:16:20 发布

海哥python

最新推荐文章于 2025-06-15 20:16:20 发布

阅读量1.2k

点赞数 31

分类专栏：面试八股文文章标签： kubernetes 容器云原生

本文链接：https://blog.youkuaiyun.com/python_9k/article/details/135769422

版权

简述 ETCD 及其特点？

etcd 是 CoreOS 团队发起的开源项目，是一个管理配置信息和服务发现（service discovery）的项目，
它的目标是构建一个高可用的分布式键值（key-value）数据库，基于 Go 语言实现。
特点：

简单：支持 REST 风格的 HTTP+JSON API
安全：支持 HTTPS 方式的访问
快速：支持并发 1k/s 的写操作
可靠：支持分布式结构，基于 Raft 的一致性算法，Raft 是一套通过选举主节点来实现分布式系统一致性的算法。

简述 ETCD 适应的场景？

etcd 基于其优秀的特点，可广泛的应用于以下场景：

服务发现 (Service Discovery) ：服务发现主要解决在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听 udp 或 tcp 端口，并且通过名字就可以查找和连接。
消息发布与订阅：在分布式系统中，最适用的一种组件间通信方式就是消息发布与订阅。即构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦主题有消息发布，就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。应用中用到的一些配置信息放到 etcd 上进行集中管理。
负载均衡：在分布式系统中，为了保证服务的高可用以及数据的一致性，通常都会把数据和服务部署多份，以此达到对等服务，即使其中的某一个服务失效了，也不影响使用。etcd 本身分布式架构存储的信息访问支持负载均衡。etcd 集群化以后，每个 etcd 的核心节点都可以处理用户的请求。所以，把数据量小但是访问频繁的消息数据直接存储到 etcd 中也可以实现负载均衡的效果。
分布式通知与协调：与消息发布和订阅类似，都用到了 etcd 中的 Watcher 机制，通过注册与异步通知机制，实现分布式环境下不同系统之间的通知与协调，从而对数据变更做到实时处理。
分布式锁：因为 etcd 使用 Raft 算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。集群监控与 Leader 竞选：通过 etcd 来进行监控实现起来非常简单并且实时性强。

简述 HAProxy 及其特性？

HAProxy 是可提供高可用性、负载均衡以及基于 TCP 和 HTTP 应用的代理，是免费、快速并且可靠的一种解决方案。HAProxy 非常适用于并发大（并发达 1w 以上）web 站点，这些站点通常又需要会话保持或七层处理。HAProxy 的运行模式使得它可以很简单安全的整合至当前的架构中，同时可以保护web 服务器不被暴露到网络上。

HAProxy 的主要特性有：

可靠性和稳定性非常好，可以与硬件级的 F5 负载均衡设备相媲美；
最高可以同时维护 40000-50000 个并发连接，单位时间内处理的最大请求数为 20000 个，最大处理能力可达 10Git/s；
支持多达 8 种负载均衡算法，同时也支持会话保持；
支持虚机主机功能，从而实现 web 负载均衡更加灵活；
支持连接拒绝、全透明代理等独特的功能；
拥有强大的 ACL 支持，用于访问控制；
其独特的弹性二叉树数据结构，使数据结构的复杂性上升到了 0(1)，即数据的查寻速度不会随着数据条目的增加而速度有所下降；
支持客户端的 keepalive 功能，减少客户端与 haproxy 的多次三次握手导致资源浪费，让多个请求在一个 tcp 连接中完成；
支持 TCP 加速，零复制功能，类似于 mmap 机制；
支持响应池（response buffering）；
支持 RDP 协议；
基于源的粘性，类似 nginx 的 ip_hash 功能，把来自同一客户端的请求在一定时间内始终调度到上游的同一服务器；
更好统计数据接口，其 web 接口显示后端集群中各个服务器的接收、发送、拒绝、错误等数据的统计信息；
详细的健康状态检测，web 接口中有关于对上游服务器的健康检测状态，并提供了一定的管理功能；
基于流量的健康评估机制；
基于 http 认证；
基于命令行的管理接口；
日志分析器，可对日志进行分析。

简述 HAProxy 常见的负载均衡策略？

HAProxy 负载均衡策略非常多，常见的有如下 8 种：

roundrobin：表示简单的轮询。
static-rr：表示根据权重。
leastconn：表示最少连接者先处理。
source：表示根据请求的源 IP，类似 Nginx 的 IP_hash 机制。
ri：表示根据请求的 URI。
rl_param：表示根据 HTTP 请求头来锁定每一次 HTTP 请求。
rdp-cookie(name)：表示根据据 cookie(name)来锁定并哈希每一次 TCP 请求。

简述负载均衡四层和七层的区别？

四层负载均衡器也称为 4 层交换机，主要通过分析 IP 层及 TCP/UDP 层的流量实现基于 IP 加端口的负载均衡，如常见的 LVS、F5 等；
七层负载均衡器也称为 7 层交换机，位于 OSI 的最高层，即应用层，此负载均衡器支持多种协议，如HTTP、FTP、SMTP 等。7 层负载均衡器可根据报文内容，配合一定的负载均衡算法来选择后端服务器，即“内容交换器”。如常见的 HAProxy、Nginx。

简述 LVS、Nginx、HAproxy 的什么异同？

相同：三者都是软件负载均衡产品。
区别：LVS 基于 Linux 操作系统实现软负载均衡，而 HAProxy 和 Nginx 是基于第三方应用实现的软负载
均衡；LVS 是可实现 4 层的 IP 负载均衡技术，无法实现基于目录、URL 的转发。而 HAProxy 和 Nginx都可以实现 4 层和 7 层技术，HAProxy 可提供 TCP 和 HTTP 应用的负载均衡综-合解决方案；
LVS 因为工作在 ISO 模型的第四层，其状态监测功能单一，而 HAProxy 在状监测方面功能更丰富、强大，可支持端口、URL、脚本等多种状态检测方式；
HAProxy 功能强大，但整体性能低于 4 层模式的 LVS 负载均衡。
Nginx 主要用于 Web 服务器或缓存服务器。

简述 Heartbeat？

Heartbeat 是 Linux-HA 项目中的一个组件，它提供了心跳检测和资源接管、集群中服务的监测、失效切换等功能。heartbeat 最核心的功能包括两个部分，心跳监测和资源接管。心跳监测可以通过网络链
路和串口进行，而且支持冗余链路，它们之间相互发送报文来告诉对方自己当前的状态，如果在指定的时间内未收到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运行在对方主机上的资源或者服务。

简述 Keepalived 及其工作原理？

Keepalived 是一个基于 VRRP 协议来实现的 LVS 服务高可用方案，可以解决静态路由出现的单点故障问题。

在一个 LVS 服务集群中通常有主服务器（MASTER）和备份服务器（BACKUP）两种角色的服务器，但是对外表现为一个虚拟 IP，主服务器会发送 VRRP 通告信息给备份服务器，当备份服务器收不到 VRRP消息的时候，即主服务器异常的时候，备份服务器就会接管虚拟 IP，继续提供服务，从而保证了高可用性。

简述 Keepalived 体系主要模块及其作用？

keepalived 体系架构中主要有三个模块，分别是 core、check 和 vrrp。

core 模块为 keepalived 的核心，负责主进程的启动、维护及全局配置文件的加载和解析。
vrrp 模块是来实现 VRRP 协议的。
check 负责健康检查，常见的方式有端口检查及 URL 检查。

简述 Keepalived 如何通过健康检查来保证高可用？

Keepalived 工作在 TCP/IP 模型的第三、四和五层，即网络层、传输层和应用层。

网络层，Keepalived 采用 ICMP 协议向服务器集群中的每个节点发送一个 ICMP 的数据包，如果某个节点没有返回响应数据包，则认为此节点发生了故障，Keepalived 将报告次节点失效，并从服务器集群中剔除故障节点。
传输层，Keepalived 利用 TCP 的端口连接和扫描技术来判断集群节点是否正常。如常见的 web服务默认端口 80，ssh 默认端口 22 等。Keepalived 一旦在传输层探测到相应端口没用响应数据返回，则认为此端口发生异常，从而将此端口对应的节点从服务器集群中剔除。
应用层，可以运行 FTP、telnet、smtp、dns 等各种不同类型的高层协议，Keepalived 的运行方式也更加全面化和复杂化，用户可以通过自定义 Keepalived 的工作方式，来设定监测各种程序或服务是否正常，若监测结果与设定的正常结果不一致，将此服务对应的节点从服务器集群中剔除。

Keepalived 通过完整的健康检查机制，保证集群中的所有节点均有效从而实现高可用。

简述 LVS 的概念及其作用？

LVS 是 linux virtual server 的简写 linux 虚拟服务器，是一个虚拟的服务器集群系统，可以在unix/linux 平台下实现负载均衡集群功能。

LVS 的主要作用是：通过 LVS 提供的负载均衡技术实现一个高性能、高可用的服务器群集。因此 LVS 主要可以实现：

把单台计算机无法承受的大规模的并发访问或数据流量分担到多台节点设备上分别处理，减少用户
等待响应的时间，提升用户体验。
单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。
7*24 小时的服务保证，任意一个或多个设备节点设备宕机，不能影响到业务。在负载均衡集群中，所有计算机节点都应该提供相同的服务，集群负载均衡获取所有对该服务的如站请求。

简述 LVS 的工作模式及其工作过程？

LVS 有三种负载均衡的模式，分别是 VS/NAT（nat 模式）、VS/DR（路由模式）、VS/TUN（隧道模式）。

NAT 模式（VS-NAT）

原理：首先负载均衡器接收到客户的请求数据包时，根据调度算法决定将请求发送给哪个后端的真实服务器（RS）。然后负载均衡器就把客户端发送的请求数据包的目标 IP 地址及端口改成后端真实服务器的 IP 地址（RIP）。真实服务器响应完请求后，查看默认路由，把响应后的数据包发送给负载均衡器，负载均衡器在接收到响应包后，把包的源地址改成虚拟地址（VIP）然后发送回给客户端。
优点：集群中的服务器可以使用任何支持 TCP/IP 的操作系统，只要负载均衡器有一个合法的 IP地址。
缺点：扩展性有限，当服务器节点增长过多时，由于所有的请求和应答都需要经过负载均衡器，因此负载均衡器将成为整个系统的瓶颈。

IP 隧道模式（VS-TUN）

原理：首先负载均衡器接收到客户的请求数据包时，根据调度算法决定将请求发送给哪个后端的真实服务器（RS）。然后负载均衡器就把客户端发送的请求报文封装一层 IP 隧道（T-IP）转发到真实服务器（RS）。真实服务器响应完请求后，查看默认路由，把响应后的数据包直接发送给客户端，不需要经过负载均衡器。
优点：负载均衡器只负责将请求包分发给后端节点服务器，而 RS 将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，也能处理很巨大的请求量。
缺点：隧道模式的 RS 节点需要合法 IP，这种方式需要所有的服务器支持“IP Tunneling”。
直接路由模式（VS-DR）
原理：首先负载均衡器接收到客户的请求数据包时，根据调度算法决定将请求发送给哪个后端的真实服务器（RS）。然后负载均衡器就把客户端发送的请求数据包的目标 MAC 地址改成后端真实服务器的 MAC 地址（R-MAC）。真实服务器响应完请求后，查看默认路由，把响应后的数据包直接发送给客户端，不需要经过负载均衡器。
优点：负载均衡器只负责将请求包分发给后端节点服务器，而 RS 将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，也能处理很巨大的请求量。
缺点：需要负载均衡器与真实服务器 RS 都有一块网卡连接到同一物理网段上，必须在同一个局域网环境。

简述 LVS 调度器常见算法（均衡策略）？

LVS 调度器用的调度方法基本分为两类：

固定调度算法：rr，wrr，dh，sh
rr：轮询算法，将请求依次分配给不同的 rs 节点，即 RS 节点中均摊分配。适合于 RS 所有节点处理性能接近的情况。
wrr：加权轮训调度，依据不同 RS 的权值分配任务。权值较高的 RS 将优先获得任务，并且分配到的连接数将比权值低的 RS 更多。相同权值的 RS 得到相同数目的连接数。
dh：目的地址哈希调度（destination hashing）以目的地址为关键字查找一个静态 hash 表来获得所需 RS。
sh：源地址哈希调度（source hashing）以源地址为关键字查找一个静态 hash 表来获得需要的RS。
动态调度算法：wlc，lc，lblc，lblcr
wlc：加权最小连接数调度，假设各台 RS 的权值依次为 Wi，当前 tcp 连接数依次为 Ti，依次去Ti/Wi 为最小的 RS 作为下一个分配的 RS。
lc：最小连接数调度（least-connection），IPVS 表存储了所有活动的连接。LB 会比较将连接请求发送到当前连接最少的 RS。
lblc：基于地址的最小连接数调度（locality-based least-connection）：将来自同一个目的地址的请求分配给同一台 RS，此时这台服务器是尚未满负荷的。否则就将这个请求分配给连接数最小的RS，并以它作为下一次分配的首先考虑。