运维⾯试题总结：Etcd、Kubernetes、Lvs、HAProxy等
集相关
简述 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，并以它作为下⼀次分配的⾸先考虑。
简述 LVS、Nginx、HAProxy 各⾃优缺点？
Nginx 的优点：
⼯作在⽹络的 7 层之上，可以针对 http 应⽤做⼀些分流的策略，⽐如针对域名、⽬录结构。Nginx 正则规则⽐ HAProxy 更为强⼤和灵活。Nginx 对⽹络稳定性的依赖⾮常⼩，理论上能 ping 通就就能进⾏负载功能，LVS 对⽹络稳定性依赖⽐较⼤，稳定要求相对更⾼。
Nginx 安装和配置、测试⽐较简单、⽅便，有清晰的⽇志⽤于排查和管理，LVS 的配置、测试就要花⽐较长的时间了。
可以承担⾼负载压⼒且稳定，⼀般能⽀撑⼏万次的并发量，负载度⽐ LVS 相对⼩些。
Nginx 可以通过端⼝检测到服务器内部的故障，⽐如根据服务器处理⽹页返回的状态码、超时等等。
Nginx 不仅仅是⼀款优秀的负载均衡器/反向代理软件，它同时也是功能强⼤的 Web 应⽤服务器。
Nginx 作为 Web 反向加速缓存越来越成熟了，速度⽐传统的 Squid 服务器更快，很多场景下都将其作为反向代理加速器。
Nginx 作为静态⽹页和图⽚服务器，这⽅⾯的性能⾮常优秀，同时第三⽅模块也很多。
Nginx 的缺点：
Nginx 仅能⽀持 http、https 和 Email 协议，这样就在适⽤范围上⾯⼩些。
对后端服务器的健康检查，只⽀持通过端⼝来检测，不⽀持通过 url 来检测。
不⽀持 Session 的直接保持，需要通过 ip_hash 来解决。
LVS 的优点：
抗负载能⼒强、是⼯作在⽹络 4 层之上仅作分发之⽤，没有流量的产⽣。因此负载均衡软件⾥的性能最强的，对内存和 cpu 资源消耗⽐较低。
LVS ⼯作稳定，因为其本⾝抗负载能⼒很强，⾃⾝有完整的双机热备⽅案。
⽆流量，LVS 只分发请求，⽽流量并不从它本⾝出去，这点保证了均衡器 IO 的性能不会收到⼤流量的影响。
应⽤范围较⼴，因为 LVS ⼯作在 4 层，所以它⼏乎可对所有应⽤做负载均衡，包括 http、数据库等。
LVS 的缺点是：
软件本⾝不⽀持正则表达式处理，不能做动静分离。相对来说，Nginx/HAProxy+Keepalived 则具有明显的优势。
如果是⽹站应⽤⽐较庞⼤的话，LVS/DR+Keepalived 实施起来就⽐较复杂了。相对来说，Nginx/HAProxy+Keepalived 就简单多了。HAProxy 的优点：
HAProxy 也是⽀持虚拟主机的。
HAProxy 的优点能够补充 Nginx 的⼀些缺点，⽐如⽀持 Session 的保持，Cookie 的引导，同时⽀持通过获取指定的 url 来检测后端服务器的状态。
HAProxy 跟 LVS 类似，本⾝就只是⼀款负载均衡软件，单纯从效率上来讲 HAProxy 会⽐ Nginx 有更出⾊的负载均衡速度，在并发处理上也是优于 Nginx 的。
HAProxy ⽀持 TCP 协议的负载均衡转发。
简述代理服务器的概念及其作⽤？
代理服务器是⼀个位于客户端和原始（资源）服务器之间的服务器，为了从原始服务器取得内容，客户端向代理服务器发送⼀个请求并指定⽬标原始服务器，然后代理服务器向原始服务器转交请求并将获得的内容返回给客户端。
其主要作⽤有：
资源获取：代替客户端实现从原始服务器的资源获取；
加速访问：代理服务器可能离原始服务器更近，从⽽起到⼀定的加速作⽤；
缓存作⽤：代理服务器保存从原始服务器所获取的资源，从⽽实现客户端快速的获取；
隐藏真实地址：代理服务器代替客户端去获取原始服务器资源，从⽽隐藏客户端真实信息。
简述⾼可⽤集可通过哪两个维度衡量⾼可⽤性，各⾃含义是什么？
RTO（Recovery Time Objective）：RTO 指服务恢复的时间，最佳的情况是 0，即服务⽴即恢复；最坏是⽆穷⼤，即服务永远⽆法恢复；RPO（Recovery Point Objective）：RPO 指指当灾难发⽣时允许丢失的数据量，0 意味着使⽤同步的数据，⼤于 0 意味着有数据丢失，
如“RPO=1 d”指恢复时使⽤⼀天前的数据，那么⼀天之内的数据就丢失了。因此，恢复的最佳情况是 RTO = RPO = 0，⼏乎⽆法实现。
简述什么是 CAP 理论？
CAP 理论指出了在分布式系统中需要满⾜的三个条件，主要包括：
Consistency（⼀致性）：所有节点在同⼀时间具有相同的数据；
Availability（可⽤性）：保证每个请求不管成功或者失败都有响应；
Partition tolerance（分区容错性）：系统中任意信息的丢失或失败不影响系统的继续运⾏。
CAP 理论的核⼼是：⼀个分布式系统不可能同时很好的满⾜⼀致性，可⽤性和分区容错性这三个需求，最多只能同时较好的满⾜两个。
简述什么是 ACID 理论？
原⼦性(Atomicity)：整体不可分割性，要么全做要不全不做；
⼀致性(Consistency)：事务执⾏前、后数据库状态均⼀致；
隔离性(Isolation)：在事务未提交前，它操作的数据，对其它⽤户不可见；
持久性 (Durable)：⼀旦事务成功，将进⾏永久的变更，记录与 redo ⽇志。
简述什么是 Kubernetes？
Kubernetes 是⼀个全新的基于容器技术的分布式系统⽀撑平台。是 Google 开源的容器集管理系统（⾕歌内部:Borg）。在 Docker 技术的基础上，为容器化的应⽤提供部署运⾏、资源调度、服务发现和动态伸缩等⼀系列完整功能，提⾼了⼤规模容器集管理的便捷性。并且具有完备的集管理能⼒，多层次的安全防护和准⼊机制、多租户应⽤⽀撑能⼒、透明的服务注册和发现机制、內建智能负载均衡器、强⼤的故障发现和⾃我修复能⼒、服务滚动升级和在线扩容能⼒、可扩展的资源⾃动调度机制以及多粒度的资源配额管理能⼒。
简述 Kubernetes 和 Docker 的关系？
Docker 提供容器的⽣命周期管理和，Docker 镜像构建运⾏时容器。它的主要优点是将将软件/应⽤程序运⾏所需的设置和依赖项打包到⼀个容器中，从⽽实现了可移植性等优点。
Kubernetes ⽤于关联和编排在多个主机上运⾏的容器。
简述 Kubernetes 中什么是 Minikube、Kubectl、Kubelet？
Minikube 是⼀种可以在本地轻松运⾏⼀个单节点 Kubernetes 集的⼯具。
Kubectl 是⼀个命令⾏⼯具，可以使⽤该⼯具控制 Kubernetes 集管理器，如检查集资源，创建、删除和更新组件，查看应⽤程序。Kubelet 是⼀个代理服务，它在每个节点上运⾏，并使从服务器与主服
务器通信。
简述 Kubernetes 常见的部署⽅式？
常见的 Kubernetes 部署⽅式有：
kubeadm：也是推荐的⼀种部署⽅式；
⼆进制：
minikube：在本地轻松运⾏⼀个单节点 Kubernetes 集的⼯具。
简述 Kubernetes 如何实现集管理？
在集管理⽅⾯，Kubernetes 将集中的机器划分为⼀个 Master 节点和⼀⼯作节点 Node。其中，在 Master 节点运⾏着集管理相关的⼀组进程 kube-apiserver、kube-controller-manager 和 kube-scheduler，这些进程实现了整个集的资源管理、Pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理能⼒，并且都是全⾃动完成的。
简述 Kubernetes 的优势、适应场景及其特点？
Kubernetes 作为⼀个完备的分布式系统⽀撑平台，其主要优势：
容器编排
轻量级
负载均衡器的作用开源
弹性伸缩
负载均衡
Kubernetes 常见场景：
快速部署应⽤
快速扩展应⽤
⽆缝对接新的应⽤功能
节省资源，优化硬件资源的使⽤
Kubernetes 相关特点：
可移植: ⽀持公有云、私有云、混合云、多重云（multi-cloud）。
可扩展: 模块化,、插件化、可挂载、可组合。
⾃动化: ⾃动部署、⾃动重启、⾃动复制、⾃动伸缩/扩展。
简述 Kubernetes 的缺点或当前的不⾜之处？
Kubernetes 当前存在的缺点（不⾜）如下：
安装过程和配置相对困难复杂。
管理服务相对繁琐。
运⾏和编译需要很多时间。
它⽐其他替代品更昂贵。
对于简单的应⽤程序来说，可能不需要涉及 Kubernetes 即可满⾜。
简述 Kubernetes 相关基础概念？
master：k8s 集的管理节点，负责管理集，提供集的资源数据访问⼊⼝。拥有 Etcd 存储服务（可选），运⾏ Api Server 进
程，Controller Manager 服务进程及 Scheduler 服务进程。
node（worker）：Node（worker）是 Kubernetes 集架构中运⾏ Pod 的服务节点，是 Kubernetes 集操作的单元，⽤来承载被分配Pod 的运⾏，是 Pod 运⾏的宿主机。运⾏ docker eninge 服务，守护进程 kunelet 及负载均衡器 kube-proxy。
pod：运⾏于 Node 节点上，若⼲相关容器的组合。Pod 内包含的容器运⾏在同⼀宿主机上，使⽤相同的⽹络命名空间、IP 地址和端⼝，能够通过 localhost 进⾏通信。Pod 是 Kurbernetes 进⾏创建、调度和管理的最⼩单位，它提供了⽐容器更⾼层次的抽象，使得部署和管理更加灵活。⼀个 Pod 可以包含⼀个容器或者多个相关容器。
label：Kubernetes 中的 Label 实质是⼀系列的 Key/Value 键值对，其中 key 与 value 可⾃定义。Label 可以附加到各种资源对象上，如Node、Pod、Service、RC 等。⼀个资源对象可以定义任意数量的 Label，同⼀个 Label 也可以被添加到任意数量的资源对象上去。Kubernetes 通过 Label Selector（标签选择器）查询和筛选资源对象。
Replication Controller：Replication Controller ⽤来管理 Pod 的副本，保证集中存在指定数量的 Pod 副本。集中副本的数量⼤于指定数量，则会停⽌指定数量之外的多余容器数量。反之，则会启动少于指定数量个数的容器，保证数量不变。Replication Controller 是实现弹性伸缩、动态扩容和滚动升级的核⼼。
Deployment：Deployment 在内部使⽤了 RS 来实现⽬的，Deployment 相当于 RC 的⼀次升级，其最⼤的特⾊为可以随时获知当前 Pod 的部署进度。
HPA（Horizontal Pod Autoscaler）：Pod 的横向⾃动扩容，也是 Kubernetes 的⼀种资源，通过追踪分析 RC 控制的所有 Pod ⽬标的负载变化情况，来确定是否需要针对性的调整 Pod 副本数量。
Service：Service 定义了 Pod 的逻辑集合和访问该集合的策略，是真实服务的抽象。Service 提供了⼀个统⼀的服务访问⼊⼝以及服务代理和发现机制，关联多个相同 Label 的 Pod，⽤户不需要了解后台 Pod 是如何运⾏。
Volume：Volume 是 Pod 中能够被多个容器访问的共享⽬录，Kubernetes 中的 Volume 是定义在 Pod 上，可以被⼀个或多个 Pod 中的容器挂载到某个⽬录下。
Namespace：Namespace ⽤于实现多租户的资源隔离，可将集内部的资源对象分配到不同的 Names
pace 中，形成逻辑上的不同项⽬、⼩组或⽤户组，便于不同的 Namespace 在共享使⽤整个集的资源的同时还能被分别管理。
简述 Kubernetes 集相关组件？
Kubernetes Master 控制组件，调度管理整个系统（集），包含如下组件:
Kubernetes API Server：作为 Kubernetes 系统的⼊⼝，其封装了核⼼对象的增删改查操作，以 RESTful API 接⼝⽅式提供给外部客户和内部组件调⽤，集内各个功能模块之间数据交互和通信的中⼼枢纽。
Kubernetes Scheduler：为新建⽴的 Pod 进⾏节点(node)选择(即分配机器)，负责集的资源调度。
Kubernetes Controller：负责执⾏各种控制器，⽬前已经提供了很多控制器来保证 Kubernetes 的正常运⾏。
Replication Controller：管理维护 Replication Controller，关联 Replication Controller 和 Pod，保证 Replication Controller 定义的副本数量与实际运⾏ Pod 数量⼀致。
Node Controller：管理维护 Node，定期检查 Node 的健康状态，标识出(失效|未失效)的 Node 节点。
Namespace Controller：管理维护 Namespace，定期清理⽆效的 Namespace，包括 Namesapce 下的 API 对象，⽐如 Pod、Service 等。Service Controller：管理维护 Service，提供负载以及服务代理。
EndPoints Controller：管理维护 Endpoints，关联 Service 和 Pod，创建 Endpoints 为 Service 的后端，当 Pod 发⽣变化时，实时更新Endpoints。
Service Account Controller：管理维护 Service Account，为每个 Namespace 创建默认的 Service Account，同时为 Service Account 创建Service Account Secret。
Persistent Volume Controller：管理维护 Persistent Volume 和 Persistent Volume Claim，为新的 Persistent Volume Claim 分配 Persistent Volume 进⾏绑定，为释放的 Persistent Volume 执⾏清理回收。
Daemon Set Controller：管理维护 Daemon Set，负责创建 Daemon Pod，保证指定的 Node 上正常的运⾏ Daemon Pod。Deployment Controller：管理维护 Deployment，关联 Deployment 和 Replication Controller，保证运⾏指定数量的 Pod。当 Deployment 更新时，控制实现 Replication Controller 和 Pod 的更新。
Job Controller：管理维护 Job，为 Jod 创建⼀次性任务 Pod，保证完成 Job 指定完成的任务数⽬
Pod Autoscaler Controller：实现 Pod 的⾃动伸缩，定时获取监控数据，进⾏策略匹配，当满⾜条件时执⾏ Pod 的伸缩动作。
简述 Kubernetes RC 的机制？
Replication Controller ⽤来管理 Pod 的副本，保证集中存在指定数量的 Pod 副本。当定义了 RC 并提交⾄ Kubernetes 集中之
后，Master 节点上的 Controller Manager 组件获悉，并同时巡检系统中当前存活的⽬标 Pod，并确保⽬标 Pod 实例的数量刚好等于此 RC 的期望值，若存在过多的 Pod 副本在运⾏，系统会停⽌⼀些 Pod，反之则⾃动创建⼀些 Pod。
简述 Kubernetes Replica Set 和 Replication Controller 之间有什么区别？
Replica Set 和 Replication Controller 类似，都是确保在任何给定时间运⾏指定数量的 Pod 副本。不同之处在于 RS 使⽤基于集合的选择器，⽽ Replication Controller 使⽤基于权限的选择器。
简述 kube-proxy 作⽤？
kube-proxy 运⾏在所有节点上，它监听 apiserver 中 service 和 endpoint 的变化情况，创建路由规则以
提供服务 IP 和负载均衡功能。简单理解此进程是 Service 的透明代理兼负载均衡器，其核⼼功能是将到某个 Service 的访问请求转发到后端的多个 Pod 实例上。
简述 kube-proxy iptables 原理？
Kubernetes 从 1.2 版本开始，将 iptables 作为 kube-proxy 的默认模式。iptables 模式下的 kube-proxy 不再起到 Proxy 的作⽤，其核⼼功能：通过 API Server 的 Watch 接⼝实时跟踪 Service 与 Endpoint 的变更信息，并更新对应的 iptables 规则，Client 的请求流量则通过iptables 的 NAT 机制“直接路由”到⽬标 Pod。
简述 kube-proxy ipvs 原理？
IPVS 在 Kubernetes1.11 中升级为 GA 稳定版。IPVS 则专门⽤于⾼性能负载均衡，并使⽤更⾼效的数据结构（Hash 表），允许⼏乎⽆限的规模扩张，因此被 kube-proxy 采纳为最新模式。
在 IPVS 模式下，使⽤ iptables 的扩展 ipset，⽽不是直接调⽤ iptables 来⽣成规则链。iptables 规则链是⼀个线性的数据结构，ipset 则引⼊了带索引的数据结构，因此当规则很多时，也可以很⾼效地查和匹配。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。