Kubernetes 常见面试题汇总

简述 etcd 及其特点？
答：etcd 是 CoreOS 团队发起的开源项目，是一个管理配置信息和服务发现（service discovery）的项目，它的目标是构建一个高可用的分布式键值（key-value）数据库，基于 Go 语言实现。特点： l 简单：支持 REST 风格的 HTTP+JSON API l 安全：支持 HTTPS 方式的访问 l 快速：支持并发 1k/s 的写操作 l 可靠：支持分布式结构，基于 Raft 的一致性算法，Raft 是一套通过选举主节点来实现分布式系统一致性的算法。
简述 etcd 适应的场景？
答：etcd 基于其优秀的特点，可广泛的应用于以下场景： l 服务发现(Service Discovery)：服务发现主要解决在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听 udp 或 tcp 端口，并且通过名字就可以查找和连接。 l 消息发布与订阅：在分布式系统中，最适用的一种组件间通信方式就是消息发布与订阅。即构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦主题有消息发布，就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。应用中用到的一些配置信息放到 etcd 上进行集中管理。 l 负载均衡：在分布式系统中，为了保证服务的高可用以及数据的一致性，通常都会把数据和服务部署多份，以此达到对等服务，即使其中的某一个服务失效了，也不影响使用。etcd 本身分布式架构存储的信息访问支持负载均衡。etcd 集群化以后，每个 etcd 的核心节点都可以处理用户的请求。所以，把数据量小但是访问频繁的消息数据直接存储到 etcd 中也可以实现负载均衡的效果。 l 分布式通知与协调：与消息发布和订阅类似，都用到了 etcd 中的 Watcher 机制，通过注册与异步通知机制，实现分布式环境下不同系统之间的通知与协调，从而对数据变更做到实时处理。 l 分布式锁：因为 etcd 使用 Raft 算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。 l 集群监控与 Leader 竞选：通过 etcd 来进行监控实现起来非常简单并且实时性强。
简述什么是 Kubernetes？
答：Kubernetes 是一个全新的基于容器技术的分布式系统支撑平台。是 Google 开源的容器集群管理系统（谷歌内部:Borg）。在 Docker 技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。并且具有完备的集群管理能力，多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。
简述 Kubernetes 和 Docker 的关系？
答：Docker 提供容器的生命周期管理和，Docker 镜像构建运行时容器。它的主要优点是将将软件/应用程序运行所需的设置和依赖项打包到一个容器中，从而实现了可移植性等优点。 Kubernetes 用于关联和编排在多个主机上运行的容器。
简述 Kubernetes 中什么是 Minikube、Kubectl、Kubelet？
答： Minikube 是一种可以在本地轻松运行一个单节点 Kubernetes 群集的工具。 Kubectl 是一个命令行工具，可以使用该工具控制 Kubernetes 集群管理器，如检查群集资源，创建、删除和更新组件，查看应用程序。 Kubelet 是一个代理服务，它在每个节点上运行，并使从服务器与主服务器通信。
简述 Kubernetes 常见的部署方式？
答：常见的 Kubernetes 部署方式有： l kubeadm：也是推荐的一种部署方式； l 二进制： l minikube：在本地轻松运行一个单节点 Kubernetes 群集的工具。
简述 Kubernetes 如何实现集群管理？
答：在集群管理方面，Kubernetes 将集群中的机器划分为一个 Master 节点和一群工作节点 Node。其中，在 Master 节点运行着集群管理相关的一组进程 kubeapiserver、kube-controller-manager 和 kube-scheduler，这些进程实现了整个集群的资源管理、Pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理能力，并且都是全自动完成的。
简述 Kubernetes 的优势、适应场景及其特点？
答： Kubernetes 作为一个完备的分布式系统支撑平台，其主要优势： l 容器编排 l 轻量级 l 开源 l 弹性伸缩 l 负载均衡 Kubernetes 常见场景： l 快速部署应用 l 快速扩展应用 l 无缝对接新的应用功能 l 节省资源，优化硬件资源的使用 Kubernetes 相关特点： l 可移植: 支持公有云、私有云、混合云、多重云（multi-cloud）。 l 可扩展: 模块化,、插件化、可挂载、可组合。 l 自动化: 自动部署、自动重启、自动复制、自动伸缩/扩展。
简述 Kubernetes 的缺点或当前的不足之处？ Kubernetes 当前存在的缺点（不足）如下：
l 安装过程和配置相对困难复杂。 l 管理服务相对繁琐。 l 运行和编译需要很多时间。 l 它比其他替代品更昂贵。 l 对于简单的应用程序来说，可能不需要涉及 Kubernetes 即可满足。
简述 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，用户不需要了解后台 Pod 是如何运行。 l Volume：Volume 是 Pod 中能够被多个容器访问的共享目录，Kubernetes 中的 Volume 是定义在 Pod 上，可以被一个或多个 Pod 中的容器挂载到某个目录下。 l Namespace：Namespace 用于实现多租户的资源隔离，可将集群内部的资源对象分配到不同的 Namespace 中，形成逻辑上的不同项目、小组或用户组，便于不同的 Namespace 在共享使用整个集群的资源的同时还能被分别管理。
简述 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 的伸缩动作。
简述 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 表），允许几乎无限的规模扩张，因此被 kubeproxy 采纳为最新模式。在 IPVS 模式下，使用 iptables 的扩展 ipset，而不是直接调用 iptables 来生成规则链。iptables 规则链是一个线性的数据结构，ipset 则引入了带索引的数据结构，因此当规则很多时，也可以很高效地查找和匹配。可以将 ipset 简单理解为一个 IP（段）的集合，这个集合的内容可以是 IP 地址、IP 网段、端口等，iptables 可以直接添加规则对这个“可变的集合”进行操作，这样做的好处在于可以大大减少 iptables 规则的数量，从而减少性能损耗。
简述 kube-proxy ipvs 和 iptables 的异同？
答：iptables 与 IPVS 都是基于 Netfilter 实现的，但因为定位不同，二者有着本质的差别：iptables 是为防火墙而设计的；IPVS 则专门用于高性能负载均衡，并使用更高效的数据结构（Hash 表），允许几乎无限的规模扩张。与 iptables 相比，IPVS 拥有以下明显优势： l 1、为大型集群提供了更好的可扩展性和性能； l 2、支持比 iptables 更复杂的复制均衡算法（最小负载、最少连接、加权等）； l 3、支持服务器健康检查和连接重试等功能； l 4、可以动态修改 ipset 的集合，即使 iptables 的规则正在使用这个集合。
简述 Kubernetes 中什么是静态 Pod？
答：静态 pod 是由 kubelet 进行管理的仅存在于特定 Node 的 Pod 上，他们不能通过 API Server 进行管理，无法与 ReplicationController、Deployment 或者 DaemonSet 进行关联，并且 kubelet 无法对他们进行健康检查。静态 Pod 总是由 kubelet 进行创建，并且总是在 kubelet 所在的 Node 上运行。
简述 Kubernetes 中 Pod 可能位于的状态？
答： l Pending：API Server 已经创建该 Pod，且 Pod 内还有一个或多个容器的镜像没有创建，包括正在下载镜像的过程。 l Running：Pod 内所有容器均已创建，且至少有一个容器处于运行状态、正在启动状态或正在重启状态。 l Succeeded：Pod 内所有容器均成功执行退出，且不会重启。 l Failed：Pod 内所有容器均已退出，但至少有一个容器退出为失败状态。 l Unknown：由于某种原因无法获取该 Pod 状态，可能由于网络通信不畅导致。
简述 Kubernetes 创建一个 Pod 的主要流程？
答：Kubernetes 中创建一个 Pod 涉及多个组件之间联动，主要流程如下： l 1、客户端提交 Pod 的配置信息（可以是 yaml 文件定义的信息）到 kubeapiserver。 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 数据中心。
简述 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 进行健康检查。
简述 Kubernetes 中 Pod 的健康检查方式？
答：对 Pod 的健康检查可以通过两类探针来检查：LivenessProbe 和 ReadinessProbe。 l LivenessProbe 探针：用于判断容器是否存活（running 状态），如果 LivenessProbe 探针探测到容器不健康，则 kubelet 将杀掉该容器，并根据容器的重启策略做相应处理。若一个容器不包含 LivenessProbe 探针，kubelet 认为该容器的 LivenessProbe 探针返回值用于是“Success”。 l ReadineeProbe 探针：用于判断容器是否启动完成（ready 状态）。如果 ReadinessProbe 探针探测到失败，则 Pod 的状态将被修改。Endpoint Controller 将从 Service 的 Endpoint 中删除包含该容器所在 Pod 的 Eenpoint。 l startupProbe 探针：启动检查机制，应用一些启动缓慢的业务，避免业务长时间启动而被上面两类探针 kill 掉。
简述 Kubernetes Pod 的 LivenessProbe 探针的常见方式？
答：kubelet 定期执行 LivenessProbe 探针来诊断容器的健康状态，通常有以下三种方式： l ExecAction：在容器内执行一个命令，若返回码为 0，则表明容器健康。 l TCPSocketAction：通过容器的 IP 地址和端口号执行 TCP 检查，若能建立 TCP 连接，则表明容器健康。 l HTTPGetAction：通过容器的 IP 地址、端口号及路径调用 HTTP Get 方法，若响应的状态码大于等于 200 且小于 400，则表明容器健康。
简述 Kubernetes Pod 的常见调度方式？
答：Kubernetes 中，Pod 通常是容器的载体，主要有如下常见调度方式： l Deployment 或 RC：该调度策略主要功能就是自动部署一个容器应用的多份副本，以及持续监控副本的数量，在集群内始终维持用户指定的副本数量。 l NodeSelector：定向调度，当需要手动指定将 Pod 调度到特定 Node 上，可以通过 Node 的标签（Label）和 Pod 的 nodeSelector 属性相匹配。 l NodeAffinity 亲和性调度：亲和性调度机制极大的扩展了 Pod 的调度能力，目前有两种节点亲和力表达： l requiredDuringSchedulingIgnoredDuringExecution：硬规则，必须满足指定的规则，调度器才可以调度 Pod 至 Node 上（类似 nodeSelector，语法不同）。 l preferredDuringSchedulingIgnoredDuringExecution：软规则，优先调度至满足的 Node 的节点，但不强求，多个优先级规则还可以设置权重值。 l Taints 和 Tolerations（污点和容忍）： l Taint：使 Node 拒绝特定 Pod 运行； l Toleration：为 Pod 的属性，表示 Pod 能容忍（运行）标注了 Taint 的 Node。
简述 Kubernetes 初始化容器（init container）？
答：init container 的运行方式与应用容器不同，它们必须先于应用容器执行完成，当设置了多个 init container 时，将按顺序逐个运行，并且只有前一个 init container 运行成功后才能运行后一个 init container。当所有 init container 都成功运行后， Kubernetes 才会初始化 Pod 的各种信息，并开始创建和运行应用容器。
简述 Kubernetes deployment 升级过程？
答： l 初始创建 Deployment 时，系统创建了一个 ReplicaSet，并按用户的需求创建了对应数量的 Pod 副本。 l 当更新 Deployment 时，系统创建了一个新的 ReplicaSet，并将其副本数量扩展到 1，然后将旧 ReplicaSet 缩减为 2。 l 之后，系统继续按照相同的更新策略对新旧两个 ReplicaSet 进行逐个调整。 l 最后，新的 ReplicaSet 运行了对应个新版本 Pod 副本，旧的 ReplicaSet 副本数量则缩减为 0。
简述 Kubernetes deployment 升级策略？
答：在 Deployment 的定义中，可以通过 spec.strategy 指定 Pod 更新的策略，目前支持两种策略：Recreate（重建）和 RollingUpdate（滚动更新），默认值为 RollingUpdate。 l Recreate：设置 spec.strategy.type=Recreate，表示 Deployment 在更新 Pod 时，会先杀掉所有正在运行的 Pod，然后创建新的 Pod。 l RollingUpdate：设置 spec.strategy.type=RollingUpdate，表示 Deployment 会以滚动更新的方式来逐个更新 Pod。同时，可以通过设置 spec.strategy.rollingUpdate 下的两个参数（maxUnavailable 和 maxSurge）来控制滚动更新的过程。
简述 Kubernetes DaemonSet 类型的资源特性？
答：DaemonSet 资源对象会在每个 Kubernetes 集群中的节点上运行，并且每个节点只能运行一个 pod，这是它和 deployment 资源对象的最大也是唯一的区别。因此，在定义 yaml 文件中，不支持定义 replicas。它的一般使用场景如下： l 在去做每个节点的日志收集工作。 l 监控每个节点的的运行状态。
简述 Kubernetes 自动扩容机制？
答：Kubernetes 使用 Horizontal Pod Autoscaler（HPA）的控制器实现基于 CPU 使用率进行自动 Pod 扩缩容的功能。HPA 控制器周期性地监测目标 Pod 的资源性能指标，并与 HPA 资源对象中的扩缩容条件进行对比，在满足条件时对 Pod 副本数量进行调整。 l HPA 原理 Kubernetes 中的某个 Metrics Server（Heapster 或自定义 Metrics Server）持续采集所有 Pod 副本的指标数据。HPA 控制器通过 Metrics Server 的 API（Heapster 的 API 或聚合 API）获取这些数据，基于用户定义的扩缩容规则进行计算，得到目标 Pod 副本数量。当目标 Pod 副本数量与当前副本数量不同时，HPA 控制器就向 Pod 的副本控制器（Deployment、RC 或 ReplicaSet）发起 scale 操作，调整 Pod 的副本数量，完成扩缩容操作。
简述 Kubernetes Service 类型？
答：通过创建 Service，可以为一组具有相同功能的容器应用提供一个统一的入口地址，并且将请求负载分发到后端的各个容器应用上。其主要类型有： l ClusterIP：虚拟的服务 IP 地址，该地址用于 Kubernetes 集群内部的 Pod 访问，在 Node 上 kube-proxy 通过设置的 iptables 规则进行转发； l NodePort：使用宿主机的端口，使能够访问各 Node 的外部客户端通过 Node 的 IP 地址和端口号就能访问服务； l LoadBalancer：使用外接负载均衡器完成到服务的负载分发，需要在 spec.status.loadBalancer 字段指定外部负载均衡器的 IP 地址，通常用于公有云。
简述 Kubernetes Service 分发后端的策略？
答：Service 负载分发的策略有：RoundRobin 和 SessionAffinity l RoundRobin：默认为轮询模式，即轮询将请求转发到后端的各个 Pod 上。 l SessionAffinity：基于客户端 IP 地址进行会话保持的模式，即第 1 次将某个客户端发起的请求转发到后端的某个 Pod 上，之后从相同的客户端发起的请求都将被转发到后端相同的 Pod 上。
简述 Kubernetes Headless Service？
答：在某些应用场景中，若需要人为指定负载均衡器，不使用 Service 提供的默认负载均衡的功能，或者应用程序希望知道属于同组服务的其他实例。Kubernetes 提供了 Headless Service 来实现这种功能，即不为 Service 设置 ClusterIP（入口 IP 地址），仅通过 Label Selector 将后端的 Pod 列表返回给调用的客户端。
简述 Kubernetes 外部如何访问集群内的服务？
答：对于 Kubernetes，集群外的客户端默认情况，无法通过 Pod 的 IP 地址或者 Service 的虚拟 IP 地址:虚拟端口号进行访问。通常可以通过以下方式进行访问 Kubernetes 集群内的服务： l 映射 Pod 到物理机：将 Pod 端口号映射到宿主机，即在 Pod 中采用 hostPort 方式，以使客户端应用能够通过物理机访问容器应用。 l 映射 Service 到物理机：将 Service 端口号映射到宿主机，即在 Service 中采用 nodePort 方式，以使客户端应用能够通过物理机访问容器应用。 l 映射 Sercie 到 LoadBalancer：通过设置 LoadBalancer 映射到云服务商提供的 LoadBalancer 地址。这种用法仅用于在公有云服务提供商的云平台上设置 Service 的场景。
简述 Kubernetes ingress？
答：Kubernetes 的 Ingress 资源对象，用于将不同 URL 的访问请求转发到后端不同的 Service，以实现 HTTP 层的业务路由机制。 Kubernetes 使用了 Ingress 策略和 Ingress Controller，两者结合并实现了一个完整的 Ingress 负载均衡器。使用 Ingress 进行负载分发时，Ingress Controller 基于 Ingress 规则将客户端请求直接转发到 Service 对应的后端 Endpoint（Pod）上，从而跳过 kube-proxy 的转发功能，kube-proxy 不再起作用，全过程为：ingress controller + ingress 规则 ----> services。同时当 Ingress Controller 提供的是对外服务，则实际上实现的是边缘路由器的功能。
简述 Kubernetes 镜像的下载策略？
答：K8s 的镜像下载策略有三种：Always、Never、IFNotPresent。 l Always：镜像标签为 latest 时，总是从指定的仓库中获取镜像。 l Never：禁止从仓库中下载镜像，也就是说只能使用本地镜像。 l IfNotPresent：仅当本地没有对应镜像时，才从目标仓库中下载。默认的镜像下载策略是：当镜像标签是 latest 时，默认策略是 Always；当镜像标签是自定义时（也就是标签不是 latest），那么默认策略是 IfNotPresent。
简述 Kubernetes 的负载均衡器？
答：负载均衡器是暴露服务的最常见和标准方式之一。根据工作环境使用两种类型的负载均衡器，即内部负载均衡器或外部负载均衡器。内部负载均衡器自动平衡负载并使用所需配置分配容器，而外部负载均衡器将流量从外部负载引导至后端容器。
简述 Kubernetes 各模块如何与 API Server 通信？
答：Kubernetes API Server 作为集群的核心，负责集群各功能模块之间的通信。集群内的各个功能模块通过 API Server 将信息存入 etcd，当需要获取和操作这些数据时，则通过 API Server 提供的 REST 接口（用 GET、LIST 或 WATCH 方法）来实现，从而实现各模块之间的信息交互。如 kubelet 进程与 API Server 的交互：每个 Node 上的 kubelet 每隔一个时间周期，就会调用一次 API Server 的 REST 接口报告自身状态，API Server 在接收到这些信息后，会将节点状态信息更新到 etcd 中。如 kube-controller-manager 进程与 API Server 的交互：kube-controller- manager 中的 Node Controller 模块通过 API Server 提供的 Watch 接口实时监控 Node 的信息，并做相应处理。如 kube-scheduler 进程与 API Server 的交互：Scheduler 通过 API Server 的 Watch 接口监听到新建 Pod 副本的信息后，会检索所有符合该 Pod 要求的 Node 列表，开始执行 Pod 调度逻辑，在调度成功后将 Pod 绑定到目标节点上。
简述 Kubernetes Scheduler 作用及实现原理？
答：Kubernetes Scheduler 是负责 Pod 调度的重要功能模块，Kubernetes Scheduler 在整个系统中承担了“承上启下”的重要功能，“承上”是指它负责接收 Controller Manager 创建的新 Pod，为其调度至目标 Node；“启下”是指调度完成后，目标 Node 上的 kubelet 服务进程接管后继工作，负责 Pod 接下来生命周期。 Kubernetes Scheduler 的作用是将待调度的 Pod（API 新创建的 Pod、Controller Manager 为补足副本而创建的 Pod 等）按照特定的调度算法和调度策略绑定（Binding）到集群中某个合适的 Node 上，并将绑定信息写入 etcd 中。在整个调度过程中涉及三个对象，分别是待调度 Pod 列表、可用 Node 列表，以及调度算法和策略。 Kubernetes Scheduler 通过调度算法调度为待调度 Pod 列表中的每个 Pod 从 Node 列表中选择一个最适合的 Node 来实现 Pod 的调度。随后，目标节点上的 kubelet 通过 API Server 监听到 Kubernetes Scheduler 产生的 Pod 绑定事件，然后获取对应的 Pod 清单，下载 Image 镜像并启动容器。
简述 Kubernetes Scheduler 使用哪两种算法将 Pod 绑定到 worker 节点？
答：Kubernetes Scheduler 根据如下两种调度算法将 Pod 绑定到最合适的工作节点： l 预选（Predicates）：输入是所有节点，输出是满足预选条件的节点。kubescheduler 根据预选策略过滤掉不满足策略的 Nodes。如果某节点的资源不足或者不满足预选策略的条件则无法通过预选。如“Node 的 label 必须与 Pod 的 Selector 一致”。 l 优选（Priorities）：输入是预选阶段筛选出的节点，优选会根据优先策略为通过预选的 Nodes 进行打分排名，选择得分最高的 Node。例如，资源越富裕、负载越小的 Node 可能具有越高的排名。
简述 Kubernetes kubelet 的作用？
答：在 Kubernetes 集群中，在每个 Node（又称 Worker）上都会启动一个 kubelet 服务进程。该进程用于处理 Master 下发到本节点的任务，管理 Pod 及 Pod 中的容器。每个 kubelet 进程都会在 API Server 上注册节点自身的信息，定期向 Master 汇报节点资源的使用情况，并通过 cAdvisor 监控容器和节点资源。
简述 Kubernetes kubelet 监控 Worker 节点资源是使用什么组件来实现的？
答：kubelet 使用 cAdvisor 对 worker 节点资源进行监控。在 Kubernetes 系统中， cAdvisor 已被默认集成到 kubelet 组件内，当 kubelet 服务启动时，它会自动启动 cAdvisor 服务，然后 cAdvisor 会实时采集所在节点的性能指标及在节点上运行的容器的性能指标。
简述 Kubernetes 如何保证集群的安全性？
答：Kubernetes 通过一系列机制来实现集群的安全控制，主要有如下不同的维度： l 基础设施方面：保证容器与其所在宿主机的隔离； l 权限方面： ¡ 最小权限原则：合理限制所有组件的权限，确保组件只执行它被授权的行为，通过限制单个组件的能力来限制它的权限范围。 ¡ 用户权限：划分普通用户和管理员的角色。 l 集群方面： ¡ API Server 的认证授权：Kubernetes 集群中所有资源的访问和变更都是通过 Kubernetes API Server 来实现的，因此需要建议采用更安全的 HTTPS 或 Token 来识别和认证客户端身份（Authentication），以及随后访问权限的授权（Authorization）环节。 ¡ API Server 的授权管理：通过授权策略来决定一个 API 调用是否合法。对合法用户进行授权并且随后在用户访问时进行鉴权，建议采用更安全的 RBAC 方式来提升集群安全授权。 ¡ 敏感数据引入 Secret 机制：对于集群敏感数据建议使用 Secret 方式进行保护。 ¡ AdmissionControl（准入机制）：对 kubernetes api 的请求过程中，顺序为：先经过认证 & 授权，然后执行准入操作，最后对目标对象进行操作。
简述 Kubernetes 准入机制？
答：在对集群进行请求时，每个准入控制代码都按照一定顺序执行。如果有一个准入控制拒绝了此次请求，那么整个请求的结果将会立即返回，并提示用户相应的 error 信息。准入控制（AdmissionControl）准入控制本质上为一段准入代码，在对 kubernetes api 的请求过程中，顺序为：先经过认证 & 授权，然后执行准入操作，最后对目标对象进行操作。常用组件（控制代码）如下： l AlwaysAdmit：允许所有请求 l AlwaysDeny：禁止所有请求，多用于测试环境。 l ServiceAccount：它将 serviceAccounts 实现了自动化，它会辅助 serviceAccount 做一些事情，比如如果 pod 没有 serviceAccount 属性，它会自动添加一个 default，并确保 pod 的 serviceAccount 始终存在。 l LimitRanger：观察所有的请求，确保没有违反已经定义好的约束条件，这些条件定义在 namespace 中 LimitRange 对象中。 l NamespaceExists：观察所有的请求，如果请求尝试创建一个不存在的 namespace，则这个请求被拒绝。
简述 Kubernetes RBAC 及其特点（优势）？
答：RBAC 是基于角色的访问控制，是一种基于个人用户的角色来管理对计算机或网络资源的访问的方法。相对于其他授权模式，RBAC 具有如下优势： l 对集群中的资源和非资源权限均有完整的覆盖。 l 整个 RBAC 完全由几个 API 对象完成，同其他 API 对象一样，可以用 kubectl 或 API 进行操作。 l 可以在运行时进行调整，无须重新启动 API Server。
简述 Kubernetes Secret 作用？
答：Secret 对象，主要作用是保管私密数据，比如密码、OAuth Tokens、SSH Keys 等信息。将这些私密信息放在 Secret 对象中比直接放在 Pod 或 Docker Image 中更安全，也更便于使用和分发。
简述 Kubernetes Secret 有哪些使用方式？
答：创建完 secret 之后，可通过如下三种方式使用： l 在创建 Pod 时，通过为 Pod 指定 Service Account 来自动使用该 Secret。 l 通过挂载该 Secret 到 Pod 来使用它。 l 在 Docker 镜像下载时使用，通过指定 Pod 的 spc.ImagePullSecrets 来引用它。
简述 Kubernetes PodSecurityPolicy 机制？
答：Kubernetes PodSecurityPolicy 是为了更精细地控制 Pod 对资源的使用方式以及提升安全策略。在开启 PodSecurityPolicy 准入控制器后，Kubernetes 默认不允许创建任何 Pod，需要创建 PodSecurityPolicy 策略和相应的 RBAC 授权策略（Authorizing Policies），Pod 才能创建成功。
简述 Kubernetes PodSecurityPolicy 机制能实现哪些安全策略？
答：在 PodSecurityPolicy 对象中可以设置不同字段来控制 Pod 运行时的各种安全策略，常见的有： l 特权模式：privileged 是否允许 Pod 以特权模式运行。 l 宿主机资源：控制 Pod 对宿主机资源的控制，如 hostPID：是否允许 Pod 共享宿主机的进程空间。 l 用户和组：设置运行容器的用户 ID（范围）或组（范围）。 l 提升权限：AllowPrivilegeEscalation：设置容器内的子进程是否可以提升权限，通常在设置非 root 用户（MustRunAsNonRoot）时进行设置。 l SELinux：进行 SELinux 的相关配置。
简述 Kubernetes 网络模型？
答：Kubernetes 网络模型中每个 Pod 都拥有一个独立的 IP 地址，并假定所有 Pod 都在一个可以直接连通的、扁平的网络空间中。所以不管它们是否运行在同一个 Node（宿主机）中，都要求它们可以直接通过对方的 IP 进行访问。设计这个原则的原因是，用户不需要额外考虑如何建立 Pod 之间的连接，也不需要考虑如何将容器端口映射到主机端口等问题。同时为每个 Pod 都设置一个 IP 地址的模型使得同一个 Pod 内的不同容器会共享同一个网络命名空间，也就是同一个 Linux 网络协议栈。这就意味着同一个 Pod 内的容器可以通过 localhost 来连接对方的端口。在 Kubernetes 的集群里，IP 是以 Pod 为单位进行分配的。一个 Pod 内部的所有容器共享一个网络堆栈（相当于一个网络命名空间，它们的 IP 地址、网络设备、配置等都是共享的）。
简述 Kubernetes CNI 模型？
答：CNI 提供了一种应用容器的插件化网络解决方案，定义对容器网络进行操作和配置的规范，通过插件的形式对 CNI 接口进行实现。CNI 仅关注在创建容器时分配网络资源，和在销毁容器时删除网络资源。在 CNI 模型中只涉及两个概念：容器和网络。 l 容器（Container）：是拥有独立 Linux 网络命名空间的环境，例如使用 Docker 或 rkt 创建的容器。容器需要拥有自己的 Linux 网络命名空间，这是加入网络的必要条件。 l 网络（Network）：表示可以互连的一组实体，这些实体拥有各自独立、唯一的 IP 地址，可以是容器、物理机或者其他网络设备（比如路由器）等。对容器网络的设置和操作都通过插件（Plugin）进行具体实现，CNI 插件包括两种类型：CNI Plugin 和 IPAM（IP Address Management）Plugin。CNI Plugin 负责为容器配置网络资源，IPAM Plugin 负责对容器的 IP 地址进行分配和管理。IPAM Plugin 作为 CNI Plugin 的一部分，与 CNI Plugin 协同工作。
简述 Kubernetes 网络策略？
答：为实现细粒度的容器间网络访问隔离策略，Kubernetes 引入 Network Policy。 Network Policy 的主要功能是对 Pod 间的网络通信进行限制和准入控制，设置允许访问或禁止访问的客户端 Pod 列表。Network Policy 定义网络策略，配合策略控制器（Policy Controller）进行策略的实现。
简述 Kubernetes 网络策略原理？
答：Network Policy 的工作原理主要为：policy controller 需要实现一个 API Listener，监听用户设置的 Network Policy 定义，并将网络访问规则通过各 Node 的 Agent 进行实际设置（Agent 则需要通过 CNI 网络插件实现）。
简述 Kubernetes 中 flannel 的作用？
答：Flannel 可以用于 Kubernetes 底层网络的实现，主要作用有： l 它能协助 Kubernetes，给每一个 Node 上的 Docker 容器都分配互相不冲突的 IP 地址。 l 它能在这些 IP 地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传递到目标容器内。
简述 Kubernetes Calico 网络组件实现原理？
答： Calico 是一个基于 BGP 的纯三层的网络方案，与 OpenStack、Kubernetes、AWS、 GCE 等云平台都能够良好地集成。 Calico 在每个计算节点都利用 Linux Kernel 实现了一个高效的 vRouter 来负责数据转发。每个 vRouter 都通过 BGP 协议把在本节点上运行的容器的路由信息向整个 Calico 网络广播，并自动设置到达其他节点的路由转发规则。 Calico 保证所有容器之间的数据流量都是通过 IP 路由的方式完成互联互通的。Calico 节点组网时可以直接利用数据中心的网络结构（L2 或者 L3），不需要额外的 NAT、隧道或者 Overlay Network，没有额外的封包解包，能够节约 CPU 运算，提高网络效率。
简述 Kubernetes 共享存储的作用？
答：Kubernetes 对于有状态的容器应用或者对数据需要持久化的应用，因此需要更加可靠的存储来保存应用产生的重要数据，以便容器应用在重建之后仍然可以使用之前的数据。因此需要使用共享存储。
简述 Kubernetes 数据持久化的方式有哪些？
答：Kubernetes 通过数据持久化来持久化保存重要数据，常见的方式有： l EmptyDir（空目录）：没有指定要挂载宿主机上的某个目录，直接由 Pod 内保部映射到宿主机上。类似于 docker 中的 manager volume。 l 场景： ¡ 只需要临时将数据保存在磁盘上，比如在合并/排序算法中； ¡ 作为两个容器的共享存储。 l 特性： ¡ 同个 pod 里面的不同容器，共享同一个持久化目录，当 pod 节点删除时， volume 的数据也会被删除。 ¡ emptyDir 的数据持久化的生命周期和使用的 pod 一致，一般是作为临时存储使用。 l Hostpath：将宿主机上已存在的目录或文件挂载到容器内部。类似于 docker 中的 bind mount 挂载方式。 ¡ 特性：增加了 pod 与节点之间的耦合。 PersistentVolume（简称 PV）：如基于 NFS 服务的 PV，也可以基于 GFS 的 PV。它的作用是统一数据持久化目录，方便管理。
简述 Kubernetes PV 和 PVC？
答： PV 是对底层网络共享存储的抽象，将共享存储定义为一种“资源”。 PVC 则是用户对存储资源的一个“申请”。
简述 Kubernetes PV 生命周期内的阶段？
答：某个 PV 在生命周期中可能处于以下 4 个阶段（Phaes）之一。 l Available：可用状态，还未与某个 PVC 绑定。 l Bound：已与某个 PVC 绑定。 l Released：绑定的 PVC 已经删除，资源已释放，但没有被集群回收。 l Failed：自动资源回收失败。
简述 Kubernetes 所支持的存储供应模式？
答：Kubernetes 支持两种资源的存储供应模式：静态模式（Static）和动态模式（Dynamic）。 l 静态模式：集群管理员手工创建许多 PV，在定义 PV 时需要将后端存储的特性进行设置。 l 动态模式：集群管理员无须手工创建 PV，而是通过 StorageClass 的设置对后端存储进行描述，标记为某种类型。此时要求 PVC 对存储的类型进行声明，系统将自动完成 PV 的创建及与 PVC 的绑定。
简述 Kubernetes CSI 模型？
答：Kubernetes CSI 是 Kubernetes 推出与容器对接的存储接口标准，存储提供方只需要基于标准接口进行存储插件的实现，就能使用 Kubernetes 的原生存储机制为容器提供存储服务。CSI 使得存储提供方的代码能和 Kubernetes 代码彻底解耦，部署也与 Kubernetes 核心组件分离，显然，存储插件的开发由提供方自行维护，就能为 Kubernetes 用户提供更多的存储功能，也更加安全可靠。 CSI 包括 CSI Controller 和 CSI Node： l CSI Controller 的主要功能是提供存储服务视角对存储资源和存储卷进行管理和操作。 l CSI Node 的主要功能是对主机（Node）上的 Volume 进行管理和操作。
简述 Kubernetes Worker 节点加入集群的过程？
答：通常需要对 Worker 节点进行扩容，从而将应用系统进行水平扩展。主要过程如下： l 1、在该 Node 上安装 Docker、kubelet 和 kube-proxy 服务； l 2、然后配置 kubelet 和 kubeproxy 的启动参数，将 Master URL 指定为当前 Kubernetes 集群 Master 的地址，最后启动这些服务； l 3、通过 kubelet 默认的自动注册机制，新的 Worker 将会自动加入现有的 Kubernetes 集群中； l 4、Kubernetes Master 在接受了新 Worker 的注册之后，会自动将其纳入当前集群的调度范围。
简述 Kubernetes Pod 如何实现对节点的资源控制？
答：Kubernetes 集群里的节点提供的资源主要是计算资源，计算资源是可计量的能被申请、分配和使用的基础资源。当前 Kubernetes 集群中的计算资源主要包括 CPU、 GPU 及 Memory。CPU 与 Memory 是被 Pod 使用的，因此在配置 Pod 时可以通过参数 CPU Request 及 Memory Request 为其中的每个容器指定所需使用的 CPU 与 Memory 量，Kubernetes 会根据 Request 的值去查找有足够资源的 Node 来调度此 Pod。通常，一个程序所使用的 CPU 与 Memory 是一个动态的量，确切地说，是一个范围，跟它的负载密切相关：负载增加时，CPU 和 Memory 的使用量也会增加。
简述 Kubernetes Requests 和 Limits 如何影响 Pod 的调度？
答：当一个 Pod 创建成功时，Kubernetes 调度器（Scheduler）会为该 Pod 选择一个节点来执行。对于每种计算资源（CPU 和 Memory）而言，每个节点都有一个能用于运行 Pod 的最大容量值。调度器在调度时，首先要确保调度后该节点上所有 Pod 的 CPU 和内存的 Requests 总和，不超过该节点能提供给 Pod 使用的 CPU 和 Memory 的最大容量值。
简述 Kubernetes Metric Service？
答：在 Kubernetes 从 1.10 版本后采用 Metrics Server 作为默认的性能数据采集和监控，主要用于提供核心指标（Core Metrics），包括 Node、Pod 的 CPU 和内存使用指标。对其他自定义指标（Custom Metrics）的监控则由 Prometheus 等组件来完成。
简述 Kubernetes 中，如何使用 EFK 实现日志的统一管理？
答：在 Kubernetes 集群环境中，通常一个完整的应用或服务涉及组件过多，建议对日志系统进行集中化管理，通常采用 EFK 实现。 EFK 是 Elasticsearch、Fluentd 和 Kibana 的组合，其各组件功能如下： l Elasticsearch：是一个搜索引擎，负责存储日志并提供查询接口； l Fluentd：负责从 Kubernetes 搜集日志，每个 node 节点上面的 fluentd 监控并收集该节点上面的系统日志，并将处理过后的日志信息发送给 Elasticsearch； l Kibana：提供了一个 Web GUI，用户可以浏览和搜索存储在 Elasticsearch 中的日志。通过在每台 node 上部署一个以 DaemonSet 方式运行的 fluentd 来收集每台 node 上的日志。Fluentd 将 docker 日志目录/var/lib/docker/containers 和/var/log 目录挂载到 Pod 中，然后 Pod 会在 node 节点的/var/log/pods 目录中创建新的目录，可以区别不同的容器日志输出，该目录下有一个日志文件链接到 /var/lib/docker/contianers 目录下的容器日志输出。
简述 Kubernetes 如何进行优雅的节点关机维护？
答：由于 Kubernetes 节点运行大量 Pod，因此在进行关机维护之前，建议先使用 kubectl drain 将该节点的 Pod 进行驱逐，然后进行关机维护。
简述 Kubernetes 集群联邦？
答：Kubernetes 集群联邦可以将多个 Kubernetes 集群作为一个集群进行管理。因此，可以在一个数据中心/云中创建多个 Kubernetes 集群，并使用集群联邦在一个地方控制/管理所有集群。
简述 Helm 及其优势？
答： Helm 是 Kubernetes 的软件包管理工具。类似 Ubuntu 中使用的 apt、Centos 中使用的 yum 或者 Python 中的 pip 一样。 Helm 能够将一组 K8S 资源打包统一管理, 是查找、共享和使用为 Kubernetes 构建的软件的最佳方式。 Helm 中通常每个包称为一个 Chart，一个 Chart 是一个目录（一般情况下会将目录进行打包压缩，形成 name-version.tgz 格式的单一文件，方便传输和存储）。 l Helm 优势在 Kubernetes 中部署一个可以使用的应用，需要涉及到很多的 Kubernetes 资源的共同协作。使用 helm 则具有如下优势： l 统一管理、配置和更新这些分散的 k8s 的应用资源文件； l 分发和复用一套应用模板； l 将应用的一系列资源当做一个软件包管理。对于应用发布者而言，可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。 l 对于使用者而言，使用 Helm 后不用需要编写复杂的应用部署文件，可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序。

故障问题及排查思路

基础流程和方法

查询 pod 的状态，适用于 pod Pending 的场景：

kubectl describe <pod-name> -n <namespace>
获取集群中的异常事件，作为排查 pod Pending 原因的补充：

kubectl get events -n <namespace> --sort-by .lastTimestamp [-w]
获取 pod 的日志，适用于 pod Error 或者 CrashLoopBack 的场景：

kubectl logs <pod-name> -n <namespace> [name-of-container, if multiple] [-f]
如果 pod 已经处于 Running 状态，并且现有的日志未能直接指出问题，则需要进入 pod 容器进一步测试，例如验证一个正在运行的进程的状态、配置，或者检查容器的网络连接。

如何访问容器
通过 exec 命令：kubectl exec -it <podName> sh。
通过 ephemeral container（需要 Kubernetes v1.23 以上版本）。
在镜像中缺乏程序二进制的前提下，执行常用排查工具和命令：
获取容器在宿主机对应的 PID：docker ps | grep k8s_<containerName>_<podName> | awk '{print $1}' | xargs docker inspect --format '{{ .State.Pid }}'
在容器的网络命名空间中执行安装于宿主机的工具：nsenter -t <PID> -n bash
退出容器的命名空间（即退出运行于该命名空间中的 shell）：exit
如何访问节点
ssh 到节点。
journalctl -xeu kubelet 查看 kubelet 日志，适用于节点 NotReady 的场景。
常见问题及排查方法
kubectl 执行结果异常
表现：

执行任意 kubectl 命令输出以下结果：

Error from server (InternalError): an error on the server (“”) has prevented the request from succeeding
etcdserver: leader changed
原因：

kubectl 和 apiserver 认证失败
apiserver 异常
通常由于 etcd 导致 apiserver 异常
etcd 异常
选举节点拓扑不满足奇数导致频繁切主
磁盘性能太差导致延迟太高甚至频繁切主
排查方法：

检查 kubectl 当前所使用的配置文件是否正确：kubectl config view

当前所使用的配置文件 ~/.kube/config 是否由该集群生成。
检查配置文件中的 server 地址和访问协议是否正确。
apiserver 和 etcd 均属于静态 pod，如果无法使用 kubectl 命令，可直接用容器运行时如 docker 检查容器的日志：

# 获取 apiserver 和 etcd 对应的 container_id
docker ps -a | grep -e k8s_kube-apiserver -e k8s_etcd
# 获取日志
docker logs <container_id> [-f]
测试 etcd 所使用的文件系统性能：

fio --rw=write --ioengine=sync --fdatasync=1 --filename=<etcd-data-dir>/iotest --size=22m --bs=2300 --name=etcdio-bench
该测试重点关注 etcd 所使用文件系统的 fsync 性能：

fsync/fdatasync/sync_file_range:
  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]
测试结果中，如上述 fsync 99.00th 的值大于 10000 usec（即 P99 > 10ms），通常认为不满足使用条件，建议更换磁盘硬件。

DNS 解析异常

表现：

应用无法连接到 kubernetes apiserver 或其他 DB、proxy 等依赖服务，错误信息里通常包含 53 端口访问超时、can’t resolve host 等。

原因与排查方法：

无法访问 kube-dns service 对应的后端 pod

应用容器内 dns 配置（/etc/resolv.conf）出错导致无法发出正常的解析请求（部分旧版本发行版和 libc 库存在该问题）

检查容器内的 /etc/resolv.conf 文件是否包含正确的 nameserver 和 search path，如：

$ cat /etc/resolv.conf
nameserver 11.96.0.10
search qfusion-admin.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
service 的负载均衡功能异常，出站请求无法 DNAT 到实际的 coreDNS 后端 pod

检查 kube-proxy pod 的运行状态。

检查应用容器所在节点是否能正常匹配 service 并完成 DNAT。

检查节点路由表是否有默认路由或 service 的路由规则，否则数据包不会被 DNAT。

检查是否存在 service 对应的 DNAT 规则，以 iptables 为例：

iptables-save | grep <serviceName>
对于每个 service 的每个端口，在 KUBE-SERVICES 中应该有1条规则和一个 KUBE-SVC-<hash> 链。

对于每个 Pod 端点，在该 KUBE-SVC-<hash> 中应该有少量的规则，以及一个KUBE-SEP-<hash> 链，其中有少量的规则。确切的规则将根据你的具体配置（包括节点端口和负载平衡器）而变化。

查询当前 NAT 记录：

conntrack -L | grep <dns-ip>
# destination
conntrack -L -d 10.32.0.1
详见 https://kubernetes.io/docs/tasks/debug/debug-application/debug-service/

跨节点容器网络异常，请求无法到达 DNS pod 所在节点

检查 CNI 插件相关组件的运行状态，执行 CNI 插件自带的健康检查或状态检查命令，以 cilium 为例：

cilium status [--verbose]
kubectl -n kube-system exec -it cilium-xrd4d -- cilium-health status
检查应用容器和 coredns 之间节点和 pod 的连通性

使用 nc 测试两个节点及 pod 之间的四层连通性：

# host1
nc -l 9999
# host2
nc -vz <host1> 9999
如果容器网络（大部分情况下）采用的是 vxlan 方案，测试 vxlan 默认使用的宿主机 8472 端口是否被阻断。

使用 netstat -lnup | grep 8472 或者 nc -lu 8472 检查 8472 UDP 端口是否已被其他程序占用。

使用 tcpdump 对 8472 端口进行抓包，判断数据包能否经由网络到达。例如：

tcpdump -i p4p1 dst port 8472 -c 1 -Xvv -nn
测试 8472 UDP 是否可使用：

#  on the server side
iperf -s -p 8472 -u
# on the client side
iperf -c 172.28.128.103 -u -p 8472 -b 1K
MTU 问题，网络拓扑中的某一中间设备设置了比发送端网卡更小的 MTU，导致部分大小超过的包被 drop。具体表现为能 ping 通，同一协议和端口有些请求能通，有些请求不通。

获取发送端网卡的 MTU：

ifconfig
# or
ip -4 -s address
使用 ping 命令对目标主机的 MTU 进行测试：

ping -M do -s 1472 [dest IP]
ICMP头部使用 8 个字节，以太网头部使用 20 个字节，ping 命令再额外发送了 1472 个字节，测试 MTU 1500 字节能否到达目标主机。

修改发送端网卡的 MTU

echo MTU=1450 >> /etc/sysconfig/network-scripts/ifcfg-eth0 # 文件名修改为网卡名称
systemctl restart network
kube-dns 对应的后端 pod 异常导致无法响应解析请求或者未包含 dns 记录

kube-dns service 不存在

检查 kube-system 命名空间下 service 以及 endpoint 的状态：

kubectl -n kube-system get svc | grep dns
kubectl -n kube-system get ep | grep dns
coreDNS pod 状态异常

使用上文介绍的 kubectl describe 和 kubectl logs 命令获取 coreDNS 的 pod 状态及日志。

coreDNS 无法响应解析或未包含指定的 dns 记录

进入应用容器以及另一任意容器，测试 coreDNS 能否完成其他容器、节点及域名的解析

请求 DNS server 的 53 端口，判断能够访问 DNS server 及其是否正在监听：nc -vz <ip-of-dns> 53
测试域名解析：dig example.com @<ip-of-dns> +trace (+trace 输出追踪信息以区分是否使用缓存)
其他域名解析工具：nslookup, host
更多排查 dns 解析有关的资料详见 https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/

TLS 证书异常

tls 证书的关键概念是多个证书形成一个有效的信任链，从主机上的服务器/叶子证书到多个中间证书，最后到根/CA证书。正是通过形成的信任链，客户端和服务器之间才能开始加密通信会话。

表现：因为 ssl/tls 原因无法完成预期的请求，错误信息通常包含 ssl/tls handshake error

原因：

未将根/CA 证书添加到可信任证书中
服务端/CA 证书已过期或未到开始生效时间（通常是因为系统时间不一致导致生成了还未到生效时间的证书）
排查方法：

使用 openssl 获取指定服务的证书信息：

openssl s_client -connect <fqdn/ip>:<port>
使用 openssl 获取指定服务（以 [localhost:6443](http://localhost:6443) 为例）的服务端证书并打印成可读格式：

openssl s_client -showcerts -connect localhost:6443 </dev/null 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text
通常可检查输出中的 Issuer（签发者）、Validity（生效时间）和 Subject（CN）。

如果遇到 x509: certificate signed by unknown authority（如 docker CLI 在访问内部的 https 镜像仓库时会抛出以上错误），说明目标服务器使用了不受信任的签发证书（如自签发证书），需要按照应用程序文档安装 CA 证书或变更与信任证书有关的配置。

路由和内核参数配置错误
表现：

无法完成对集群内部或外部某些状态正常服务的访问，报错信息中通常包含 Unreachable 或者 Connection timeout。

原因：

应用所在的 pod 或主机的路由表中无访问地址对应的路由项，且没有配置默认路由。
与路由有关的内核参数未正确配置或在安装 kubernetes 时开启之后被其他服务重置。
排查方法：

使用 netcat 或者 curl 测试服务端是否可通过四层网络访问：

nc -vz <ip/fqdn> <port>
curl -kL telnet://<ip/fqdn>:<port> -vvv
使用 curl 简单测试网络延迟：

curl -s -w 'Total time: %{time_total}s\n' http://example.com
打印系统路由表，注意检查是否存在默认路由：

route -n
# or
ip route show
查询指定 IP 的路由规则：

ip route get 10.101.203.141
跟踪请求的路由路径：

traceroute 10.101.203.141
traceroute 默认使用 ICMP 协议的 ECHO 包，部分设备可能不会响应。

net.ipv4.ip_forward：允许 Linux 在不同网络接口间转发流量的核心参数，绝大部分 CNI 要求启用此参数才能实现 pod 间访问。

sysctl net.ipv4.ip_forward
# this will turn things back on a live server
sysctl -w net.ipv4.ip_forward=1
# on Centos this will make the setting apply after reboot
echo net.ipv4.ip_forward=1 >> /etc/sysconf.d/10-ipv4-forwarding-on.conf
net.bridge.bridge-nf-call-iptables：允许对 Linux Bridge 设备使用 iptables 规则，部分基于 Linux Bridge 的 CNI 需要启用此参数实现容器请求外部网络的 NAT。

sysctl net.bridge.bridge-nf-call-iptables
modprobe br_netfilter
# turn the iptables setting on
sysctl -w net.bridge.bridge-nf-call-iptables=1
echo net.bridge.bridge-nf-call-iptables=1 >> /etc/sysconf.d/10-bridge-nf-call-iptables.conf
net.ipv4.conf.all.rp_filter：部分 CNI （如 Cilium）要求启用此参数实现 pod 间访问，但一些发行版版本的 systemd 可能会覆盖此参数。

cat <<EOF > /etc/sysctl.d/99-override_cilium_rp_filter.conf
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.lxc*.rp_filter = 0
EOF
systemctl restart systemd-sysctl

防火墙

表现：

请求被某些 4 层或者 7 层防火墙规则拦截，通常表现为可以访问节点但无法访问部分端口；部分请求无法完成，报错信息中通常包含 Connection Reset。

原因：

4 层防火墙禁止访问某些端口或者特定协议。
7 层防火墙审计请求的目标路径和请求体内容。
排查方法：

nc -vz 可测试四层连通性，curl -kL 可测试七层连通性，如果一个服务四层通但是七层不通，表明可能有七层防火墙。

使用 tcpdump 进行抓包分析，重点关注 ACK 为 RST 或者 Reject 的 TCP 包。

检查 iptables 是否有 reject 规则，-reject-with icmp-host-unreachable 也可能表现为有路由规则但是请求返回 no route to host。

iptables -nvL | grep -i reject
配置错误和程序 BUG
表现：

部分应用无法正常启动或按照预定配置运行，错误信息通常包含 syntax error

原因：

空格或者 tab 导致配置文件格式出现错误

如果以上排查步骤均未发现问题，且在应用容器的日志中发现了可疑的信息，可直接向开发者报告或讨论该问题，但注意不要急于给出结论。

Jack He

Kubernetes 常见面试题汇总

Kubernetes 常见面试题汇总

故障问题及排查思路

基础流程和方法

DNS 解析异常

TLS 证书异常

防火墙

Further reading

公告