云原⽣：K8s（Kubernetes）⾼频典型⾯试题汇总
谭⼀笑，左太冲云世今天
收录于话题
#云原⽣146个内容
#K8s架构34个内容
#⾯试技能18个内容
（⽂末提供最新【云原⽣系列课程】（DDD、K8s、ServiceMesh、微服务、Docker、Go语⾔学习）+【职场软技能】（架构师⾯试技能、管理实践、职场技能）免费资料获取路径）
1. 简述 etcd 及其特点？
答：etcd 是 CoreOS 团队发起的开源项⽬，是⼀个管理配置信息和服务发现（service discovery）的项⽬，它的⽬标是构建⼀个⾼可⽤的分布式键值（key-value）数据库，基于 Go 语⾔实现。
特点：
l 简单：⽀持 REST 风格的 HTTP+JSON API
l 安全：⽀持 HTTPS ⽅式的访问
l 快速：⽀持并发 1k/s 的写操作
l 可靠：⽀持分布式结构，基于 Raft 的⼀致性算法，Raft 是⼀套通过选举主节点来实现分布式系统⼀致性的算法。
2. 简述 etcd 适应的场景？
答：etcd 基于其优秀的特点，可⼴泛的应⽤于以下场景：
l 服务发现(Service Discovery)：服务发现主要解决在同⼀个分布式集中的进程或服务，要如何才能到对⽅并建⽴连接。本质上来说，服务发现就是想要了解集中是否有进程在监听 udp 或 tcp 端⼝，并且通过名字就可以查和连接。
l 消息发布与订阅：在分布式系统中，最适⽤的⼀种组件间通信⽅式就是消息发布与订阅。即构建⼀个配置共享中⼼，数据提供者在这个配置中⼼发布消息，⽽消息使⽤者则订阅他们关⼼的主题，⼀旦主题有消息发布，就会实时通知订阅者。
通过这种⽅式可以做到分布式系统配置的集中式管理与动态更新。应⽤中⽤到的⼀些配置信息放到 etcd 上进⾏集中管理。
l 负载均衡：在分布式系统中，为了保证服务的⾼可⽤以及数据的⼀致性，通常都会把数据和服务部署多份，以此达到对等服务，即使其中的某⼀个服务失效了，也不影响使⽤。etcd 本⾝分布式架构存储的信息访问⽀持负载均衡。etcd 集化以后，每个 etcd 的核⼼节点都可以处理⽤户的请求。所以，把数据量⼩但是访问频繁的消息数据直接存储到 etcd 中也可以实现负载均衡的效果。
l 分布式通知与协调：与消息发布和订阅类似，都⽤到了 etcd 中的 Watcher 机制，通过注册与异步通知机制，实现分布式环境下不同系统之间的通知与协调，从⽽对数据变更做到实时处理。
l 分布式锁：因为 etcd 使⽤ Raft 算法保持了数据的强⼀致性，某次操作存储到集
中的值必然是全局⼀致的，所以很容易实现分布式锁。锁服务有两种使⽤⽅式，⼀是保持独占，⼆是控制时序。
l 集监控与 Leader 竞选：通过 etcd 来进⾏监控实现起来⾮常简单并且实时性强。
3. 简述什么是 Kubernetes？
答：Kubernetes 是⼀个全新的基于容器技术的分布式系统⽀撑平台。是 Google 开源的容器集管理系统（⾕歌内部:Borg）。在 Docker 技术的基础上，为容器化的应⽤提供部署运⾏、资源调度、服务发现和动态伸缩等⼀系列完整功能，提⾼了⼤规模容器集管理的便捷性。并且具有完备的集管理能⼒，多层次的安全防护和准⼊机制、多租户应⽤⽀撑能⼒、透明的服务注册和发现机制、內建智能负载均衡器、强⼤的故障发现和⾃我修复能⼒、服务滚动升级和在线扩容能⼒、可扩展的资源⾃动调度机制以及多粒度的资源配额管理能⼒。
4. 简述 Kubernetes 和 Docker 的关系？
答：Docker 提供容器的⽣命周期管理和，Docker 镜像构建运⾏时容器。它的主要优点是将将软件/应⽤程序运⾏所需的设置和依赖项打包到⼀个容器中，从⽽实现了可移植性等优点。
Kubernetes ⽤于关联和编排在多个主机上运⾏的容器。
5. 简述 Kubernetes 中什么是 Minikube、Kubectl、Kubelet？
答：
Minikube 是⼀种可以在本地轻松运⾏⼀个单节点 Kubernetes 集的⼯具。
Kubectl 是⼀个命令⾏⼯具，可以使⽤该⼯具控制 Kubernetes 集管理器，如检查集资源，创建、删除和更新组件，查看应⽤程序。
Kubelet 是⼀个代理服务，它在每个节点上运⾏，并使从服务器与主服务器通信。
6. 简述 Kubernetes 常见的部署⽅式？
答：常见的 Kubernetes 部署⽅式有：
l kubeadm：也是推荐的⼀种部署⽅式；
l ⼆进制：
l minikube：在本地轻松运⾏⼀个单节点 Kubernetes 集的⼯具。
7. 简述 Kubernetes 如何实现集管理？
答：在集管理⽅⾯，Kubernetes 将集中的机器划分为⼀个 Master 节点和⼀⼯作节点 Node。其中，在 Master 节点运⾏着集管理相关的⼀组进程 kube- apiserver、kube-controller-manager 和 kube-scheduler，这些进程实现了整个集的资源管理、Pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理能⼒，并且都是全⾃动完成的。
8. 简述 Kubernetes 的优势、适应场景及其特点？
答：Kubernetes 作为⼀个完备的分布式系统⽀撑平台，其主要优势：
l 容器编排
l 轻量级
l 开源
l 弹性伸缩
l 负载均衡
Kubernetes 常见场景：
l 快速部署应⽤
l 快速扩展应⽤
l ⽆缝对接新的应⽤功能
l 节省资源，优化硬件资源的使⽤
Kubernetes 相关特点：
l 可移植: ⽀持公有云、私有云、混合云、多重云（multi-cloud）。
l 可扩展: 模块化,、插件化、可挂载、可组合。
l ⾃动化: ⾃动部署、⾃动重启、⾃动复制、⾃动伸缩/扩展。
9. 简述 Kubernetes 的缺点或当前的不⾜之处？
Kubernetes 当前存在的缺点（不⾜）如下：
l 安装过程和配置相对困难复杂。
l 管理服务相对繁琐。
l 运⾏和编译需要很多时间。
l 它⽐其他替代品更昂贵。
l 对于简单的应⽤程序来说，可能不需要涉及 Kubernetes 即可满⾜。
10. 简述 Kubernetes 相关基础概念？
答：
l master：k8s 集的管理节点，负责管理集，提供集的资源数据访问⼊⼝。拥有 Etcd 存储服务（可选），运⾏ Api Server 进
程，Controller Manager 服务进程及 Scheduler 服务进程。
l node（worker）：Node（worker）是 Kubernetes 集架构中运⾏ Pod 的服务节点，是 Kubernetes 集操作的单元，⽤来承载被分
配 Pod 的运⾏，是 Pod 运⾏的宿主机。运⾏ docker eninge 服务，守护进程kunelet 及负载均衡器kube-proxy。
l pod：运⾏于 Node 节点上，若⼲相关容器的组合。Pod 内包含的容器运⾏在同⼀宿主机上，使⽤相同的⽹络命名空间、IP 地址和端⼝，能够通过 localhost 进⾏通信。Pod 是Kurbernetes 进⾏创建、调度和管理的最⼩单位，它提供了⽐容器更⾼层次的抽象，使得部署和管理更加灵活。⼀个 Pod 可以包含⼀个容器或者多个相关容器。
l label：Kubernetes 中的 Label 实质是⼀系列的 Key/Value 键值对，其中 key 与value 可⾃定义。Label 可以附加到各种资源对象上，
如 Node、Pod、Service、RC 等。⼀个资源对象可以定义任意数量的 Label，同⼀个Label 也可以被添加到任意数量的资源对象上去。Kubernetes 通过 Label Selector（标签选择器）查询和筛选资源对象。
l Replication Controller：Replication Controller ⽤来管理 Pod 的副本，保证集中存在指定数量的 Pod 副本。集中副本的数量⼤于指定数量，则会停⽌指定数量之外的多余容器数量。反之，则会启动少于指定数量个数的容器，保证数量不变。Replication Controller 是实现弹性伸缩、动态扩容和滚动升级的核⼼。
l Deployment：Deployment 在内部使⽤了 RS 来实现⽬的，Deployment 相当
于 RC 的⼀次升级，其最⼤的特⾊为可以随时获知当前 Pod 的部署进度。
l HPA（Horizontal Pod Autoscaler）：Pod 的横向⾃动扩容，也是 Kubernetes 的⼀种资源，通过追踪分析RC 控制的所有 Pod ⽬标的负载变化情况，来确定是否需要针对性的调整 Pod 副本数量。
l Service：Service 定义了 Pod 的逻辑集合和访问该集合的策略，是真实服务的抽象。Service 提供了⼀个统⼀的服务访问⼊⼝以及服务代理和发现机制，关联多个相同Label 的 Pod，⽤户不需要了解后台 Po
d 是如何运⾏。
l Volume：Volume 是 Pod 中能够被多个容器访问的共享⽬录，Kubernetes 中的Volume 是定义在 Pod 上，可以被⼀个或多个 Pod 中的容器挂载到某个⽬录下。
l Namespace：Namespace ⽤于实现多租户的资源隔离，可将集内部的资源对象分配到不同的Namespace 中，形成逻辑上的不同项⽬、⼩组或⽤户组，便于不同的 Namespace 在共享使⽤整个集的资源的同时还能被分别管理。
11. 简述 Kubernetes 集相关组件？
答：Kubernetes Master 控制组件，调度管理整个系统（集），包含如下组件:
l Kubernetes API Server：作为 Kubernetes 系统的⼊⼝，其封装了核⼼对象的增删改查操作，以RESTful API 接⼝⽅式提供给外部客户和内部组件调⽤，集内各个功能模块之间数据交互和通信的中⼼枢纽。
l Kubernetes Scheduler：为新建⽴的 Pod 进⾏节点(node)选择(即分配机器)，负
责集的资源调度。
l Kubernetes Controller：负责执⾏各种控制器，⽬前已经提供了很多控制器来保证Kubernetes 的正常运⾏。
l Replication Controller：管理维护 Replication Controller，关联 Replication Controller 和 Pod，保证Replication Controller 定义的副本数量与实际运⾏Pod 数量⼀致。
l Node Controller：管理维护 Node，定期检查 Node 的健康状态，标识出(失效| 未失效)的 Node 节点。
l Namespace Controller：管理维护 Namespace，定期清理⽆效的 Namespace，
包括 Namesapce 下的 API 对象，⽐如 Pod、Service 等。
l Service Controller：管理维护 Service，提供负载以及服务代理。
l EndPoints Controller：管理维护 Endpoints，关联 Service 和 Pod，创建Endpoints 为 Service 的后端，当 Pod 发⽣变化时，实时更
新 Endpoints。
l Service Account Controller：管理维护 Service Account，为每个 Namespace 创建默认的Service Account，同时为 Service Account 创建 Service Account Secret。
l Persistent Volume Controller：管理维护 Persistent Volume 和 Persistent Volume Claim，为新的Persistent Volume Claim 分
配 Persistent Volume 进⾏绑定，为释放的 Persistent Volume 执⾏清理回收。
l Daemon Set Controller：管理维护 Daemon Set，负责创建 Daemon Pod，保证指定的 Node 上正常的运⾏Daemon Pod。
l Deployment Controller：管理维护 Deployment，关联 Deployment 和Replication Controller，保证运⾏指定数量的 Pod。
当 Deployment 更新时，控制实现 Replication Controller 和 Pod 的更新。
l Job Controller：管理维护 Job，为 Jod 创建⼀次性任务 Pod，保证完成 Job 指定完成的任务数⽬
l Pod Autoscaler Controller：实现 Pod 的⾃动伸缩，定时获取监控数据，进⾏策略匹配，当满⾜条件时执⾏Pod 的伸缩动作。
12. 简述 Kubernetes RC 的机制？
答：Replication Controller ⽤来管理 Pod 的副本，保证集中存在指定数量的 Pod 副本。当定义了 RC 并提交⾄Kubernetes 集中之后，Master 节点上的 Controller Manager 组件获悉，并同时巡检系统中当前存活的⽬标Pod，并确保⽬标 Pod 实例的数量刚好等于此 RC 的期望值，若存在过多的 Pod 副本在运⾏，系统会停⽌⼀些Pod，反之则⾃动创建⼀些 Pod。
13. 简述 Kubernetes Replica Set 和 Replication Controller 之间有什么区别？
答：Replica Set 和 Replication Controller 类似，都是确保在任何给定时间运⾏指定数量的 Pod 副本。不同之处在于 RS 使⽤基于集合的选择器，⽽ Replication Controller 使⽤基于权限的选择器。
14. 简述 kube-proxy 作⽤？
答：kube-proxy 运⾏在所有节点上，它监听 apiserver 中 service 和 endpoint 的变化情况，创建路由规则以提供服务 IP 和负载均衡功能。简单理解此进程是 Service 的透明代理兼负载均衡器，其核⼼功能是将到某个 Service 的访问请求转发到后端的多个 Pod 实例上。
15. 简述 kube-proxy iptables 原理？
答：Kubernetes 从 1.2 版本开始，将 iptables 作为 kube-proxy 的默认模式。iptables 模式下的 kube-proxy 不再起到 Proxy 的作⽤，其核⼼功能：通过 API Server 的Watch 接⼝实时跟踪 Service 与Endpoi
nt 的变更信息，并更新对应的iptables 规则，Client 的请求流量则通过iptables 的 NAT 机制“直接路由”到⽬标Pod。
16. 简述 kube-proxy ipvs 原理？
答：IPVS 在 Kubernetes1.11 中升级为 GA 稳定版。IPVS 则专门⽤于⾼性能负载均衡，并使⽤更⾼效的数据结构（Hash 表），允许⼏乎⽆限的规模扩张，因此被 kube-
proxy 采纳为最新模式。
负载均衡器的作用在 IPVS 模式下，使⽤ iptables 的扩展 ipset，⽽不是直接调⽤ iptables 来⽣成规则链。iptables 规则链是⼀个线性的数据结构，ipset 则引⼊了带索引的数据结构，因此当规则很多时，也可以很⾼效地查和匹配。
可以将 ipset 简单理解为⼀个 IP（段）的集合，这个集合的内容可以是 IP 地址、IP ⽹段、端⼝等，iptables 可以直接添加规则对这个“可变的集合”进⾏操作，这样做的好处在于可以⼤⼤减少 iptables 规则的数量，从⽽减少性能损耗。
17. 简述 kube-proxy ipvs 和 iptables 的异同？
答：iptables 与 IPVS 都是基于 Netfilter 实现的，但因为定位不同，⼆者有着本质的差别：iptables 是为防⽕墙⽽设计的；IPVS 则专门⽤于⾼性能负载均衡，并使⽤更⾼效的数据结构（Hash 表），允许⼏乎⽆限的规模扩张。
与 iptables 相⽐，IPVS 拥有以下明显优势：
l 1、为⼤型集提供了更好的可扩展性和性能；
l 2、⽀持⽐ iptables 更复杂的复制均衡算法（最⼩负载、最少连接、加权等）；
l 3、⽀持服务器健康检查和连接重试等功能；
l 4、可以动态修改 ipset 的集合，即使 iptables 的规则正在使⽤这个集合。
18. 简述 Kubernetes 中什么是静态 Pod？
答：静态 pod 是由 kubelet 进⾏管理的仅存在于特定 Node 的 Pod 上，他们不能通过 API Server 进⾏管理，⽆法与 ReplicationController、Deployment 或者DaemonSet 进⾏关联，并且 kubelet ⽆法对他们进⾏健康检查。静态 Pod 总是由kubelet 进⾏创建，并且总是在 kubelet 所在的 Node 上运⾏。
19. 简述 Kubernetes 中 Pod 可能位于的状态？
答：
l Pending：API Server 已经创建该 Pod，且 Pod 内还有⼀个或多个容器的镜像没
有创建，包括正在下载镜像的过程。
l Running：Pod 内所有容器均已创建，且⾄少有⼀个容器处于运⾏状态、正在启
动状态或正在重启状态。
l Succeeded：Pod 内所有容器均成功执⾏退出，且不会重启。
l Failed：Pod 内所有容器均已退出，但⾄少有⼀个容器退出为失败状态。
l Unknown：由于某种原因⽆法获取该 Pod 状态，可能由于⽹络通信不畅导致。
20. 简述 Kubernetes 创建⼀个 Pod 的主要流程？
答：Kubernetes 中创建⼀个 Pod 涉及多个组件之间联动，主要流程如下：
l 1、客户端提交 Pod 的配置信息（可以是 yaml ⽂件定义的信息）到 kube- apiserver。
l 2、Apiserver 收到指令后，通知给 controller-manager 创建⼀个资源对象。
l 3、Controller-manager 通过 api-server 将 pod 的配置信息存储到 ETCD 数据中⼼中。
l 4、Kube-scheduler 检测到 pod 信息会开始调度预选，会先过滤掉不符合 Pod
资源配置要求的节点，然后开始调度调优，主要是挑选出更适合运⾏ pod 的节点，
然后将 pod 的资源配置单发送到 node 节点上的 kubelet 组件上。
l 5、Kubelet 根据 scheduler 发来的资源配置单运⾏ pod，运⾏成功后，将 pod 的运⾏信息返回给scheduler，scheduler 将返回的 pod 运⾏状况的信息存储到etcd 数据中⼼。
21. 简述 Kubernetes 中 Pod 的重启策略？
答：Pod 重启策略（RestartPolicy）应⽤于 Pod 内的所有容器，并且仅在 Pod 所处的 Node 上由 kubelet 进⾏判断和重启操作。当某个容器异常退出或者健康检查失败时，kubelet 将根据 RestartPolicy 的设置来进⾏相应操作。
Pod 的重启策略包括 Always、OnFailure 和 Never，默认值为 Always。
l Always：当容器失效时，由 kubelet ⾃动重启该容器；
l OnFailure：当容器终⽌运⾏且退出码不为 0 时，由 kubelet ⾃动重启该容器；
l Never：不论容器运⾏状态如何，kubelet 都不会重启该容器。
同时 Pod 的重启策略与控制⽅式关联，当前可⽤于管理 Pod 的控制器包括ReplicationController、Job、DaemonSet 及直接管理 kubelet 管理（静态 Pod）。不同控制器的重启策略限制如下：
l RC 和 DaemonSet：必须设置为 Always，需要保证该容器持续运⾏；
l Job：OnFailure 或 Never，确保容器执⾏完成后不再重启；
l kubelet：在 Pod 失效时重启，不论将 RestartPolicy 设置为何值，也不会对 Pod 进⾏健康检查。

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