Kubernetes 面试题全维度精解，带你从菜鸟变身高手

一、简述什么是Kubernetes？

Kubernetes是一个基于容器技术的全新分布式系统支撑平台，源自Google开源的容器集群管理系统（谷歌内部为Borg）。它构建于Docker技术之上，为容器化应用提供了一整套完整功能，包括部署运行、资源调度、服务发现以及动态伸缩等，极大提升了大规模容器集群管理的便捷性。

Kubernetes具备完备的集群管理能力，拥有多层次的安全防护与准入机制，支持多租户应用。其透明的服务注册和发现机制，能确保服务的高效查找与连接；内建智能负载均衡器，可实现流量的合理分配。此外，它还拥有强大的故障发现及自我修复能力，具备服务滚动升级和在线扩容能力，提供可扩展的资源自动调度机制，以及多粒度的资源配额管理能力，全方位满足复杂业务场景下对容器集群管理的多样化需求。

二、深入解析K8s中Pod的创建与销毁过程

在Kubernetes中，Pod作为最小的调度单元，通常用于承载一个或多个紧密协作的容器。Pod的创建与销毁，是Kubernetes集群运行过程中的关键操作，这一过程涉及多个组件的协同交互以及状态的复杂变更。接下来，我们将详细阐述Pod的创建和销毁流程。

创建过程

步骤一：用户发起请求

• 用户可通过kubectl命令行工具，或者直接调用Kubernetes API来提交创建Pod的请求。常见方式有使用kubectl run、kubectl apply等命令，亦或是编写描述Pod配置的YAML文件，并将其提交至集群。
• 此请求中包含了Pod的详细配置信息，涵盖容器镜像、资源限制、环境变量、卷设置、端口定义等关键内容。

步骤二：请求处理

• Kubernetes的API Server作为整个集群的统一入口，负责处理所有的HTTP请求。当收到Pod创建请求后，API Server会对请求依次进行验证与授权（基于RBAC及其他相关策略）：
  • 验证环节：检查请求是否严格遵循Kubernetes的API规范，例如Pod配置的语法是否正确、字段使用是否恰当等。
  • 授权环节：确认发起请求的用户具备足够权限来执行Pod创建操作。
• 若请求顺利通过验证与授权，API Server会将Pod配置信息存储至Etcd中。Etcd是一款强一致性的数据库，承担着存储Kubernetes集群所有状态信息的重任。

步骤三：调度器选择节点

• Kubernetes Scheduler持续监控Etcd中Pod的状态信息，并依据一系列因素挑选合适的节点来运行该Pod：
  • 资源请求考量：综合评估Pod对CPU和内存资源的需求。
  • 节点资源分析：分析节点当前的负载情况以及可用资源余量。
  • 亲和性与反亲和性规则：参照Pod针对节点设定的亲和性或反亲和性规则（例如，某些Pod需部署在同一节点，而某些Pod则需避免与特定Pod共处同一节点）。
  • 污点与容忍策略：判断节点是否存在污点，以及Pod是否对这些污点具备容忍能力。
• 调度器选定节点后，会更新Pod的配置，明确指定该Pod将在选定节点上运行。

步骤四：启动容器

• Kubelet作为每个节点上的代理组件，肩负着确保容器在节点上正常运行的使命。当调度器确定Pod的运行节点后，Kubelet会接收该节点上Pod的详细信息。
• Kubelet依据Pod配置启动容器，确保容器按预期启动，具体操作如下：
  • 若节点上不存在所需的容器镜像，Kubelet会自动下载镜像。
  • 严格依照Pod配置启动容器。
  • 若涉及卷的使用，Kubelet会将相应的存储资源挂载至容器内。
• Kubelet启动容器后，会定期将容器的运行状态汇报给API Server，以此确保Pod的状态始终处于健康可监测状态。

步骤五：服务发现与网络配置

• Kube Proxy负责为Pod配置网络规则，保障服务能够顺利发现并访问该Pod。若Pod通过Service对外暴露服务，Kube Proxy会更新Service的后端列表，将新创建的Pod纳入其中。
• Kubernetes的DNS服务会为Pod分配专属的DNS名称，使得Pod可通过DNS解析实现访问。

步骤六：状态更新

• 当Pod成功完成调度并启动后，Kubernetes API Server会将Pod的状态更新为Running，并将这一状态信息同步保存至Etcd中。在此阶段，Pod的IP地址及其他元数据也会一并完成更新 。

销毁过程

步骤一：用户或控制器发起删除请求

• Pod的销毁操作，通常由用户借助kubectl delete pod <pod_name>命令触发，也可能由诸如Deployment、StatefulSet等控制器发起。
• 当控制器检测到实际状态与期望状态出现偏差时，便会启动Pod删除流程。例如，在Deployment中，若Pod副本数量发生调整，控制器会针对超出期望数量的Pod发起删除请求 。

步骤二：处理删除请求

• API Server在接收到删除请求后，首要任务是对请求的合法性展开验证。
• 验证通过后，API Server会将删除请求状态同步至Etcd，此时Pod的状态被更新为Terminating 。

步骤三：停止容器

• Kubelet一旦检测到Pod被标记为Terminating，便会即刻启动容器的终止流程，具体执行以下操作：
  • 向Pod内的容器发送终止信号（例如SIGTERM）。
  • 设定一段等待时间（即Grace Period），给予容器充足时间进行优雅关闭。
  • 若容器在规定时间内未能正常退出，Kubelet将发送强制终止信号（如SIGKILL） 。

步骤四：清理容器资源

• Kubelet负责清理与容器及Pod相关的各类资源，主要涵盖以下方面：
  • 删除容器运行时所占用的资源。
  • 若Pod涉及卷的使用，Kubelet会释放并卸载相应的卷资源。
  • 清除容器的网络配置 。

步骤五：集群状态更新

• Kubernetes API Server会将Pod的状态更新为Deleted，并从Etcd中移除Pod的所有相关数据。
• 若Pod由Deployment这类控制器管理，控制器会依据更新后的状态，启动新的Pod，以此维持预设的副本数量 。

步骤六：清理网络资源

• Kube Proxy会对服务的后端列表进行更新，将已删除Pod的IP地址从列表中移除，从而确保网络流量不再被路由至该Pod 。

总结

• Pod创建过程：起始于用户向API Server提交请求，经调度器选定运行节点后，由Kubelet负责启动容器，最终完成状态更新并将服务对外暴露 。
• Pod销毁过程：从用户或控制器发起删除请求开始，API Server将Pod标记为Terminating，随后Kubelet执行容器的优雅终止操作，直至完成所有资源清理并更新状态 。

整个过程高度依赖Kubernetes的多个核心组件，包括API Server、Scheduler、Kubelet、Kube Proxy等，各组件协同运作，确保Pod的创建与销毁过程实现自动化、具备高效性且维持状态一致性 。

三、etcd里读写到底是怎么回事？

etcd是一个分布式键值存储系统，在像Kubernetes这样的容器编排平台里用得特别多，专门用来存储和共享配置信息、系统状态、服务发现相关数据等。它的设计目标就是要实现高可用性、保证强一致性，还要能做到线性化读取 。

读写的原理

etcd是基于Raft协议运行的，Raft是一种一致性算法，主要作用就是在分布式系统里保证数据一致。etcd借助Raft协议，在分布式环境中达成强一致性。下面讲讲etcd里读写操作的基本原理。

写操作原理

• 选个“领导”来管事：etcd集群里的所有节点会通过Raft协议选出一个领导者（Leader）。这个领导者专门负责处理所有写操作。只有它能接收客户端发起的写请求，比如说往里面存数据的Put请求。
• 大家一起记日志：领导者节点接到写请求后，会先把这个写操作（比如更新某个键值对）记录在自己的本地日志里，接着把这个日志条目发给集群里所有的跟随者（Follower）节点。跟随者节点收到后，也会把这个日志条目写到自己的日志里，然后给领导者发确认消息。
• 确定操作完成：当大多数节点（包括领导者自己）都确认收到并写入了这个日志条目，领导者节点就会把这个操作标记为已提交（commit），然后把提交结果反馈给客户端。到这时候，写操作才算是真正做完了，而且整个集群里的数据也达成了一致。
• 保证数据一致：因为Raft协议保证了日志条目的顺序一致和提交一致，etcd里的每个写操作都能确保强一致性。这就意味着，不管在哪个节点上，写操作的结果都是一样的，每个客户端看到的数据也都是最新的 。

读操作原理

• 从哪儿读取数据：etcd允许客户端从任意节点读取数据。不过，为了保证数据的强一致性，客户端一般会优先选择从领导者节点读取。毕竟领导者节点掌握着最新数据，所有写请求都是它处理的，也负责确保日志条目提交 。
• 灵活读取模式：etcd也支持从跟随者节点读取数据。为了避免每次读都得找领导者节点，etcd提供了一致性读取和强一致性读取两种模式：
  • 一致性读取：读取请求可以直接发给任何节点（包括跟随者）。这些节点会返回自己保存的最新数据，但这个数据不一定是在整个集群里都完全一致的。要是集群里数据还没同步好或者正在更新，可能就会返回旧数据。
  • 强一致性读取：客户端向领导者节点发起请求，这样就能确保读到的是已经提交的最新数据，也就是最新的写操作结果，保证读取到的数据在全局是一致的。
• 确保读取一致：etcd依靠Raft协议保证读取的一致性。只要有写操作提交了，在这之后的所有读操作都能看到这个写操作的结果，这就保证了读取的线性化 。

读写操作流程简单概括

客户端写入数据流程：

• 客户端向etcd发送写请求。
• 请求被送到集群中的领导者节点。
• 领导者节点把写请求记录到日志，并且把日志同步给跟随者节点。
• 所有节点确认日志后，领导者提交该操作，给客户端返回响应 。

客户端读取数据流程：

• 客户端可以选择从任意节点读取。
• 如果客户端想读取最新数据，就向领导者节点请求。
• 如果客户端从跟随者节点读取数据，可能会看到旧数据，除非使用强一致性读取方式 。

事务与高级特性

etcd支持原子操作，通过compare-and-swap（CAS）机制保证对键值的修改是原子性的。它还具备乐观锁和事务操作功能，能把多个操作组合成一个单独事务来执行，确保数据一致性 。

总结

etcd的读写操作原理离不开Raft协议的日志复制和一致性保障机制。写操作由领导者节点处理，保证数据在集群里同步一致；读操作既可以从领导者节点获取强一致数据，也能从跟随者节点读取非强一致数据。这种机制让etcd在分布式环境中实现了强一致性和高可用性，非常适合存储分布式系统里的配置信息和状态数据 。

四、精通Kubernetes究竟意味着什么

精通Kubernetes，代表着在理解、配置、管理、故障排查以及优化等多个维度，都具备深厚扎实的技术能力，能够充分且高效地运用Kubernetes所提供的各类功能，构建并管理高性能、可灵活扩展的容器化应用。具体而言，精通Kubernetes涵盖以下众多关键层面：

深入洞悉架构

• Kubernetes核心组件：透彻掌握诸如API Server、Scheduler、Controller Manager、Kubelet、Kube Proxy等核心组件的工作原理，以及它们彼此之间的交互协作机制。
• 资源对象深度理解：对Pod、Deployment、ReplicaSet、StatefulSet、DaemonSet、Job、CronJob等Kubernetes资源对象有详尽认知，并且能够依据实际业务场景，精准合理地选择适配的资源对象。
• 节点角色与功能把控：清晰明确Master节点和Worker节点各自承担的角色和具备的功能，懂得如何妥善管理并高效调度容器化应用在这些节点上运行。

高效部署与管理容器化应用

• 应用部署利器运用：能够熟练运用Helm、Kustomize等工具，将Kubernetes上的应用部署流程予以简化并实现自动化，大幅提升部署效率。
• 无缝更新与快速回滚：在Kubernetes环境中，熟练实现应用的滚动更新，确保更新过程无停机，并且在遭遇故障时，能够迅速果断地执行回滚操作。
• 多环境适配管理：熟悉不同环境，包括开发、测试、生产环境的特性差异，掌握在这些环境中对Kubernetes集群进行有效管理与精准配置的技巧。

服务发现与负载均衡掌控

• 服务内外暴露操作：熟练运用Kubernetes的Service资源，实现负载均衡、DNS解析以及端口映射等功能，助力内部服务顺畅运行并对外安全暴露。
• Ingress控制器配置管理：能够熟练完成Ingress控制器的配置与管理工作，精准掌控外部流量的访问路径与规则。
• Service Mesh实践运用：深刻理解并能够灵活运用Service Mesh（例如Istio）技术，实现微服务之间高效稳定的通信、全方位的监控以及严格的安全性控制。

存储与持久化能力

• 存储体系认知与选型：全面理解Kubernetes中的存储体系，依据应用的具体存储需求，从NFS、GlusterFS、Ceph、云存储等众多存储类型中，挑选出最合适的方案。
• 有状态应用存储配置：能够为有状态的应用，如数据库等，高效配置持久化存储，确保数据的稳定可靠存储与读取。
• 动态卷供应配置运用：借助StorageClass实现动态卷供应的配置，以满足高效、灵活的存储需求，提升存储资源的利用效率。

安全性管理专长

• RBAC权限精细控制：熟练运用Kubernetes基于角色的访问控制（RBAC）机制，对集群访问权限进行精细且严格的管控。
• 网络策略定制保障：能够针对不同的Pod和服务，定制并实施网络策略，切实保障集群内外网络环境的安全性。
• 敏感信息妥善管理：运用Kubernetes Secret妥善管理敏感信息，确保应用配置过程中的安全性。

集群监控与日志管理能力

• 监控工具熟练运用：熟练使用Prometheus、Grafana等工具，对集群及应用进行实时、全方位的监控，并灵活设置告警机制，及时发现潜在问题。
• 日志管理与故障排查：借助ELK Stack、Fluentd、EFK等日志收集与分析工具，高效开展集群日志管理工作，为故障排查提供有力支撑。

性能优化与故障排除技能

• 精准性能调优：根据不同工作负载的特性与需求，精准优化集群资源配置，例如合理设定CPU和内存资源的请求与限制。
• 高效故障诊断解决：凭借kubectl命令、日志信息、监控数据以及事件分析等多种手段，快速准确地诊断并解决集群中出现的各类问题。
• 高可用与灾难恢复保障：能够完成高可用Kubernetes集群的配置与管理工作，确保集群在面临单点故障等突发状况时，依然能够稳定可靠地运行。

自定义与扩展能力

• 自定义资源与控制器创建：能够运用CRD（Custom Resource Definition）对Kubernetes进行扩展，自主创建并有效管理自定义资源对象。
• Operator模式实践运用：深入理解并能够成功实现Kubernetes Operator，以此自动化管理复杂的、有状态的应用，提升应用管理效率。

集成与自动化能力

• CI/CD工具集成：能够将Kubernetes与Jenkins、GitLab CI/CD等CI/CD工具紧密集成，实现应用的自动化构建、测试与部署流程。
• GitOps流程落地实施：借助Argo CD、Flux等工具，将基于GitOps的持续交付理念落地实施，提升应用交付的规范性与高效性。

多集群管理与服务网格运用

• 跨集群通信与管理：掌握如何对多个Kubernetes集群进行有效管理，以及实现集群之间顺畅的服务发现与通信。
• Service Mesh深度运用：熟练运用Service Mesh技术，如Istio，妥善处理跨服务的流量管理、安全控制、负载均衡等复杂问题。

总结

精通Kubernetes，绝非仅仅局限于知晓如何创建和管理Kubernetes集群，而是要对其架构设计、调度策略制定、安全性保障、应用部署流程、存储管理方法、监控体系搭建、日志管理机制等各个层面，进行全面且深入的掌握。精通Kubernetes的工程师，能够游刃有余地进行容器化应用的设计、部署、管理、优化以及故障排查等工作，切实保障容器化应用运行的高效性、安全性以及可扩展性 。

五、当容器类服务出现故障，该如何排查？

当容器化服务遭遇故障时，我们需要采用系统性的方法，从多个层面深入剖析问题。以下是一套通用的排查思路，能够助力你高效定位并解决问题。

检查容器状态与日志

查看容器运行状态

• 若使用Docker，可运用docker ps命令；要是在Kubernetes环境下，则通过kubectl get pods指令，以此确认容器或Pod是否处于正常运行状态。一旦容器呈现“CrashLoopBackOff”或“Error”状态，极有可能是容器启动失败，或是在运行过程中发生崩溃 。

查阅容器日志信息

• 在Docker场景中，使用docker logs命令；对应Kubernetes环境，执行kubectl logs指令，查看容器的日志输出。这些日志往往能直观呈现容器内部出现的错误，诸如应用程序崩溃、依赖项缺失等关键信息 。

深入应用日志排查

• 若容器内运行的是应用程序，务必查看应用自身的日志，从中洞察是否存在业务逻辑错误、异常情况，或者数据库连接方面的问题等 。

排查资源相关问题

关注内存与CPU资源使用

• 倘若容器因资源匮乏而崩溃，可借助docker stats（Docker环境）或kubectl top pod（Kubernetes环境）命令，查看资源实时使用状况。一旦发现某个容器超出其预设的CPU或内存资源限制，此时便需要考虑增加资源配额，或者对应用进行优化 。

确认磁盘空间是否充足

• 要确认宿主机或者Kubernetes节点的磁盘空间是否充裕，尤其是像/var/lib/docker这类用于存储容器镜像和日志的关键路径。一旦磁盘空间不足，极有可能致使容器运行失败 。

排查网络方面问题

测试网络连接情况

• 检查容器能否正常访问其他服务，例如数据库、外部API等。在Docker环境下，使用docker exec ping [target]命令；在Kubernetes环境中，执行kubectl exec [pod_name] -- ping [target]指令，以此测试网络连通性 。

排查DNS配置问题

• 容器内部的DNS配置有可能存在偏差，进而导致无法解析域名。此时可查看容器中的/etc/resolv.conf文件，核实DNS配置是否准确无误 。

检查防火墙与安全组设置

• 仔细检查宿主机或者云平台的防火墙、安全组设置，确保其未对容器之间的通信，或者外部对容器的访问造成阻碍 。

排查配置是否有误

核对环境变量设置

• 务必确保容器中所设置的环境变量精准无误，诸如数据库连接字符串、API密钥等关键信息。一旦环境变量缺失或者设置错误，应用程序很可能无法正常启动，或者无法顺利连接到外部服务 。

检查配置文件状态

• 容器的配置文件可能被错误修改，进而致使应用无法正常运作。要确保配置文件的路径正确，内容无误，特别是在Kubernetes中使用ConfigMap或Secret来管理配置时，更需谨慎核对 。

排查容器镜像相关问题

确认镜像拉取是否成功

• 若容器无法启动，需检查镜像是否成功拉取。在Docker环境下，可运用docker pull命令来验证镜像是否可用；在Kubernetes环境中，通过kubectl describe pod指令查看详细错误信息，判断是否存在镜像拉取失败的状况 。

核查镜像版本是否正确

• 确认容器所运行的镜像版本准确无误。若应用依赖特定版本的镜像，务必保证版本号和标签完全匹配，避免使用过时或者错误的镜像 。

排查依赖服务问题

检查数据库及外部服务可达性

• 确认容器能否访问其依赖的数据库或外部服务。通过docker exec或kubectl exec命令进入容器内部，手动尝试连接数据库或外部服务，以此确认其是否可达 。

确认依赖服务运行状态

• 确保容器所依赖的其他服务，如Redis、Kafka、API服务等，均处于正常运行状态。仔细检查这些服务的运行状况，查看是否存在故障 。

检查容器的健康状况

审视Kubernetes健康检查设置

• 若在Kubernetes环境中运用了livenessProbe和readinessProbe，需仔细检查健康检查的配置是否正确，避免容器被错误标记为不健康或者不可用。通过kubectl describe pod指令，查看关于探针的详细信息 。

查看Docker健康检查结果

• 针对Docker容器，可使用docker inspect命令检查容器的健康状态。若容器运用了HEALTHCHECK指令，需留意健康检查的最终结果 。

排查集群及容器编排平台问题

检查Kubernetes集群状态

• 倘若故障发生在Kubernetes集群中的容器，需查看集群状态是否正常。运用kubectl get nodes指令，查看节点状态，确保集群内不存在不可用的节点 。

排查资源调度异常

• 检查Kubernetes的调度器是否存在问题，以防某些容器因调度异常，无法被合理调度至合适的节点。可查看调度器的日志（kubectl logs -n kube-system），了解详细情况 。

查看事件与警告信息

关注Kubernetes事件详情

• 运用kubectl get events指令，查看与容器或Pod相关的事件。这些事件往往能提供诸多关键信息，例如容器启动失败、资源不足、调度失败等 。

  查阅容器运行时警告与错误

• 查看Docker或Kubernetes运行时的日志（如journalctl或/var/log/docker.log），从中或许能获取额外的警告信息，或是导致故障的根本原因 。

总结

排查容器故障的关键在于从多个维度进行全面分析，涵盖容器自身状态、网络连通性、资源使用情况、配置准确性、镜像完整性以及依赖服务的稳定性等。通过系统且有条理的排查与诊断流程，能够高效定位问题根源，并采取切实有效的解决措施。在Kubernetes环境中，充分借助kubectl等工具以及日志系统，能够进一步提升问题定位的效率 。

六、深入剖析Kubernetes各重要组件

Kubernetes（K8s）作为一款功能强大的容器编排平台，致力于实现应用程序容器部署、扩展及管理的自动化。它由众多组件构成，每个组件都在Kubernetes系统中扮演着不可或缺的关键角色。以下是对Kubernetes各关键组件的详尽理解：

API Server（服务器）

• 核心作用：API Server是Kubernetes控制平面的核心组件，堪称所有用户请求的总入口。它不仅要接收并处理外部诸如kubectl命令等用户请求，还要处理集群内各组件的内部请求。同时，API Server提供RESTful API接口，方便用户与Kubernetes控制平面的其他组件进行交互。
• 工作原理：API Server在接收到请求后，会先对请求进行验证和认证，接着依据请求类型（例如GET、POST、PUT等）与Etcd存储进行交互。此外，它还会借助授权（RBAC）和准入控制器（Admission Controller）来确保请求符合权限规定和策略要求。

Etcd（配置管理数据库）

• 关键作用：Etcd是一个分布式键值存储系统，用于存储Kubernetes集群的全部配置信息和状态数据，比如集群配置、Pod状态、节点信息等。
• 工作原理：Etcd通过强一致性机制来保障集群数据的一致性。Kubernetes中的所有状态信息，包括Pod、Service、ConfigMap、Secret等，都会存储在Etcd中，这使得它能够支持数据的高可用性以及灾难恢复。

Scheduler（调度器）

• 主要作用：Scheduler负责将尚未指定运行节点的Pod调度到合适的节点上。它会综合考虑资源需求、亲和性、反亲和性、污点和容忍等多种规则，进而做出合理的调度决策。
• 工作原理：Scheduler从API Server获取等待调度的Pod列表，然后根据集群中各个节点的资源状况，如CPU、内存、磁盘等资源的使用情况，来决定将Pod安排在哪个节点上。在决策过程中，它会充分考虑节点的负载情况、约束条件（例如节点选择器、亲和性等）以及其他相关的调度策略。

Controller Manager（控制器管理器）

• 核心职责：Controller Manager运行着多个控制器，承担着维护Kubernetes集群状态的重要任务。这些控制器本质上是循环控制系统，确保集群中的实际状态与期望状态保持一致。
• 工作原理：Controller Manager包含多个不同功能的控制器，如Replication Controller、Deployment Controller、StatefulSet Controller等。每个控制器都专注监视集群的某一个特定方面，并保证系统状态始终处于一致状态。例如，Deployment Controller会确保部署的Pod数量与期望的副本数量相符，一旦Pod的健康检查失败，它会自动重新创建Pod。

Kubelet（节点管理代理）

• 重要作用：Kubelet是Kubernetes中每个节点上的代理组件，主要负责管理节点上的容器，确保容器在节点上能够正常稳定地运行。
• 工作原理：Kubelet会定期向API Server汇报节点和容器的状态，并且始终保证本地的Pod和容器状态与API Server中记录的期望状态一致。一旦容器出现崩溃或者需要重新启动的情况，Kubelet会及时处理容器的启动和重启操作。

Kube Proxy（服务代理）

• 关键功能：Kube Proxy负责集群内的网络代理和负载均衡工作。它主要管理Kubernetes中服务的访问，通过实施负载均衡策略，将流量合理地分发到集群中的各个Pod。
• 工作原理：Kube Proxy会实时监听Kubernetes服务资源的变化情况，并为每个服务创建相应的负载均衡规则。它支持三种不同的负载均衡模式，分别是基于iptables、基于IPVS和基于用户空间的代理。Kube Proxy能够确保用户和外部流量可以正确访问集群内的服务，并且根据负载均衡策略将请求准确转发到对应的Pod。

Ingress Controller（控制器）

• 主要作用：Ingress Controller是专门负责处理集群外部HTTP和HTTPS流量的组件。它基于Ingress资源，能够提供HTTP路由、SSL/TLS终端等重要功能。
• 工作原理：Ingress资源定义了外部访问服务的具体规则，而Ingress Controller会依据这些规则来配置外部访问的路由和负载均衡。它可以让多个服务共享同一个负载均衡器，并根据请求的路径或主机名，将流量精准转发到不同的后端服务。

Namespace（命名空间）

• 关键作用：Namespace是Kubernetes中的一种资源隔离机制，它允许在同一个集群中创建多个虚拟集群。每个命名空间内的资源，比如Pod、Service、ConfigMap等，都是相互独立的。
• 工作原理：命名空间主要用于组织集群中的资源，并且在大规模集群中实现资源隔离。在多租户环境下，不同的团队或项目可以在各自的命名空间中管理资源，从而有效避免资源冲突。

Volume（存储卷）

• 重要作用：Volume是Kubernetes提供的一种持久化存储解决方案，容器内的数据可以存储在Volume中，这样即使容器重启或迁移，数据依然能够保持可用。
• 工作原理：Volume的生命周期与Pod绑定，它可以挂载到Pod中的容器上。Kubernetes支持多种类型的Volume，例如HostPath、NFS、Ceph、云服务提供商的存储服务等，并且通过Persistent Volume（PV）和Persistent Volume Claim（PVC）来实现对存储资源的动态管理。

Service（服务）

• 核心作用：Service是Kubernetes中的一个抽象层，主要用于定义一组Pod的访问方式，通常是通过负载均衡器来提供稳定的网络访问。
• 工作原理：Service提供了一种便捷访问Pod的方法，它能够自动发现并对所有后端Pod的流量进行负载均衡。通过ClusterIP、NodePort、LoadBalancer等不同类型的Service，用户可以灵活定义不同的访问方式和策略。

ConfigMap和Secret（配置和机密管理）

• 关键作用：ConfigMap和Secret是用于管理应用程序配置和敏感信息的资源对象。其中，ConfigMap用于存储非敏感的配置信息，而Secret则用于存储机密信息，如数据库密码、API密钥等。
• 工作原理：ConfigMap和Secret允许在容器中以环境变量、命令行参数或挂载文件的形式提供配置信息。这些信息可以在Pod中动态更新，从而减少应用程序中的硬编码配置。

总结

Kubernetes 的每个组件都有着独特且明确的职责，它们通过API和内部通信相互协作，共同保障整个集群的可靠性、可扩展性和高可用性。深入理解这些组件的作用和工作原理，对于高效管理和维护Kubernetes集群来说，是至关重要的基础。

七、深入解析K8s里的资源调度

在Kubernetes的世界中，资源调度是一项核心任务，它指的是将容器化的应用程序（通常以Pod的形式存在）合理分配到集群内各个节点上的过程。Kubernetes的调度系统就像是一位精明的指挥官，精准决定着哪些Pod该运行在哪些节点上，以此实现集群资源的高效利用与负载均衡。

资源调度的基本概念

1. Pod：作为Kubernetes里最小的调度单元，一个Pod可以容纳一个或多个容器，它们紧密协作，共同完成特定的业务功能。
2. 节点：这些是Kubernetes集群中的“劳动力”，通常表现为虚拟机或者物理机，承担着承载和运行Pod的重任。
3. 调度器：Kubernetes的调度器（Scheduler）是整个调度过程的“大脑”，专门负责把那些尚未指定运行节点的Pod，调度到合适的节点上去。

资源调度的关键组件和步骤

调度器：决策的核心

调度器是Kubernetes中做出Pod调度决策的关键组件。它会综合考量以下几个重要因素，从而挑选出最合适的节点：

• 资源需求：Pod在运行过程中所请求的CPU、内存以及存储等资源，是调度器首要考虑的因素之一。
• 节点资源：调度器会密切关注各个节点上的可用资源情况，通过细致检查各节点的资源使用状况，来挑选出最合适的节点。
• 调度策略：预定义的调度策略，如亲和性、反亲和性、污点和容忍等，也是调度器筛选节点的重要依据。

节点选择：多因素考量

调度器基于多种因素来为Pod选择合适的运行节点，具体会从以下几个方面进行考量：

• 资源请求和限制：每个Pod都能够明确指定CPU和内存的请求（request）与限制（limit）。调度器会严格依据这些需求来挑选节点。只有当某个节点的资源足以满足Pod的请求时，调度器才会将该节点纳入考虑范围。
• 节点亲和性（Node Affinity）：这种机制允许我们根据节点的标签，将Pod精准调度到特定的节点上。例如，我们可以把某些Pod调度到带有特定标签（像zone=us - west - 1）的节点上。
• Pod亲和性和反亲和性（Pod Affinity and Anti - Affinity）：Pod亲和性能够帮助我们控制Pod的调度规则，使得某些Pod可以被安排在一起运行，比如让它们在同一节点上共享资源。而Pod反亲和性则是为了确保某些Pod不会被调度到一起，避免因共享资源过多而导致性能问题。
• 污点和容忍（Taints and Tolerations）：这是一种特殊的机制，用于给某些节点打上“不适合”运行某些Pod的标记。污点就像是节点的特殊“标签”，表明该节点不适合运行某些类型的Pod，除非这些Pod具备相应的容忍（Toleration）。这种机制常用于标记那些只能运行特定类型Pod的节点，比如配备专用硬件（如GPU）的节点。
• 负载均衡：调度器会时刻关注集群中各个节点的负载情况，以此来均衡调度Pod。如果某个节点的资源已经接近饱和状态，调度器就会优先选择资源比较空闲的节点来调度新的Pod。

调度算法和优先级：精准决策

调度器会依据不同的优先级和算法，来判断哪个节点最适合运行某个Pod。Kubernetes调度器主要通过以下机制来做出决策：

• Filter（过滤）：调度器会先进行一轮筛选，把那些不符合条件的节点剔除出去。例如，如果某个节点的资源无法满足Pod的请求，或者该节点上正在运行着不允许该Pod运行的服务，那么这个节点就会被排除在候选名单之外。
• Score（打分）：在经过过滤后剩余的候选节点中，调度器会根据各节点的具体条件和预设策略进行打分，最终选择得分最高的节点。
• 优先级：Kubernetes支持根据不同的调度策略来设置优先级。比如，优先选择资源空闲的节点，或者根据节点标签、硬件特性（如GPU支持）来挑选节点。

容器调度中的资源管理：合理分配

• 请求（Request）与限制（Limit）：请求代表着容器启动时所需要的最小资源（如CPU和内存），调度器会根据这个请求来评估是否有足够资源的节点可以运行Pod。而限制则是容器的最大资源使用上限，如果容器的资源使用超过了这个限制，Kubernetes会采取相应措施（如杀掉容器）来控制资源的使用。合理配置请求和限制，能够确保容器的资源得到有效分配，避免节点资源过载。
• Resource Quotas（资源配额）：Kubernetes允许在命名空间级别设置资源配额，以此来限制每个命名空间中可以使用的资源总量。资源配额就像是一个“资源阀门”，可以有效控制不同团队或服务对资源的占用情况，防止单个应用占用过多的集群资源。

调度器的扩展性：灵活定制

• 自定义调度器：Kubernetes赋予了用户自定义调度器的能力，用户可以针对特定需求（如性能优化、特定硬件需求等）设计属于自己的调度策略。例如，Kubernetes可以同时使用多个调度器，针对某些特殊硬件（如GPU）使用自定义调度器，而对于其他常规工作负载则使用默认调度器，以此满足更复杂的调度需求。

Pod的生命周期管理：协同保障

像Deployment、StatefulSet、DaemonSet、ReplicaSet等Pod管理控制器，会确保Pod始终按照期望的状态运行。调度器会与这些控制器紧密协作，保证Pod能够被正确调度，并且根据实际需求进行扩展。

总结

Kubernetes的资源调度是一个错综复杂的过程，它涉及到对节点资源的精细管理、多种调度策略的灵活应用以及优先级的精准判断。调度器在集群资源分配中扮演着至关重要的角色，它能够确保容器根据资源请求、亲和性、污点和容忍等规则，高效且可靠地运行在合适的节点上。此外，调度器还具备高度的可扩展性和自定义功能，使得Kubernetes能够灵活适应各种不同的使用场景和负载要求。

八、常见 CNI 插件使用经验及区别分析

在 Kubernetes 环境里，CNI（Container Network Interface）插件扮演着至关重要的角色，它们的主要任务是为容器之间提供网络连接，并对这些连接进行管理。不同的 CNI 插件在网络架构、性能表现、具备的功能以及适用场景等方面存在显著差异。下面为你介绍一些常见的 CNI 插件，并详细阐述它们之间的区别。

Flannel：简单实用的早期网络插件

Flannel 是 Kubernetes 网络插件中的先驱者之一，因其简单易用的特性，在生产环境中得到了广泛的应用。

特点

• 设置简便：Flannel 的设置过程极为简单，其核心功能在于为 Pod 分配网络地址。
• 多后端支持：它支持多种后端实现方式，像 VXLAN、host - gw、AWS VPC 等。其中，VXLAN 模式最为常见，它会对容器流量进行封装，然后通过 UDP 通道进行传输。
• 单一网络模型：Flannel 所提供的网络模型不具备多租户功能，仅仅是为每个节点提供了 IP 地址池，以支持 Pod 之间的直接通信。

优点

• 部署轻松：简单易用的特性使其非常适合小型和中型集群。
• 独立性强：不依赖外部服务，部署过程更加便捷。

缺点

• 功能有限：仅支持平面网络，缺乏高级的网络策略和 QoS 功能。
• 扩展性弱：网络隔离性较差，只适用于简单场景，难以满足复杂的网络需求。

Calico：功能强大的网络解决方案

Calico 是一款功能强大的网络插件，能够支持高性能的容器网络、灵活的网络策略以及多云环境。

特点

• 强大的网络策略：作为 Kubernetes 中最受欢迎的 CNI 插件之一，Calico 提供了强大的网络策略功能，可以对流量进行细粒度的控制，包括 Ingress 和 Egress 策略。
• BGP 路由支持：Calico 使用 BGP 协议来提供跨节点的路由信息，同时也支持 IP - in - IP 模式来封装流量。
• 高性能表现：它直接利用 Linux 内核的路由功能，从而提供了非常高的性能。
• 网络隔离支持：通过 NetworkPolicy，Calico 可以对不同的应用和租户进行流量控制和隔离。

优点

• 性能卓越：适用于大规模的生产环境，能够满足高并发的网络需求。
• 功能完备：提供完整的网络策略功能，支持跨云环境和混合云部署。
• 高度可定制：支持多种后端（BGP、VXLAN、IP - in - IP），可以根据不同的需求进行灵活配置。

缺点

• 配置复杂：配置和维护的难度相对较高，需要一定的专业知识。
• 硬件依赖：在某些环境下，可能需要额外的网络硬件支持（如 BGP 路由）。

Cilium：基于 eBPF 技术的创新插件

Cilium 基于 eBPF（extended Berkeley Packet Filter）技术构建，具备高性能、高灵活性和强大的网络安全能力，尤其适合现代云原生架构。

特点

• eBPF 内核级控制：Cilium 使用 eBPF 进行内核级流量控制，相比传统网络插件，具有更低的延迟和更高的吞吐量。
• 高级网络安全：提供高级的 L7（应用层）网络策略，支持基于 HTTP、gRPC 等协议的细粒度流量控制。
• 多租户支持：支持容器网络的细粒度隔离，非常适合多租户和微服务架构。
• 性能优化：由于 eBPF 可以直接操作 Linux 内核，因此 Cilium 的性能表现十分出色。

优点

• 极致性能：基于 eBPF 技术，提供极低的延迟和高吞吐量。
• 安全增强：提供 L7 网络策略支持，大大增强了网络安全性能。
• 云原生适配：可以在云原生环境中使用，支持微服务和多租户隔离。
• 集成性好：能够更好地与容器安全和监控工具集成。

缺点

• 技术门槛高：需要对 eBPF 和内核级编程有一定的了解，配置过程较为复杂。
• 内核版本要求高：对旧版本的内核支持有限，需要 Linux 4.8 或更高版本。

Weave Net：高效便捷的网络连接插件

Weave Net 是一款高效的 Kubernetes 网络插件，能够自动实现容器间的网络连接。

特点

• 简单易用：Weave Net 提供了简单的安装和配置过程，无需外部依赖即可正常工作。
• 加密支持：支持端到端加密，确保容器通信的安全性。
• 跨主机通信：能够自动将不同主机上的 Pod 连接到同一个网络中，支持跨主机的容器通信。

优点

• 快速部署：简单易用的特性使其非常适合快速部署和测试环境。
• 安全通信：支持容器间的加密通信，保障数据传输的安全性。
• 便捷组网：支持跨主机网络，无需配置额外的路由，降低了组网难度。

缺点

• 性能瓶颈：性能相对较低，无法满足高性能网络需求的场景。
• 功能局限：相比于 Calico，网络策略功能较弱，扩展性有限。

Canal：融合优势的组合插件

Canal 是 Calico 和 Flannel 的结合体，它巧妙地利用 Flannel 处理网络和 IP 地址管理，同时借助 Calico 提供强大的网络策略功能。

特点

• 优势互补：结合了 Flannel 的简易性和 Calico 的强大功能，既提供了简单的网络部署方式，又具备强大的网络策略支持。
• 可扩展性强：支持 IP - in - IP、VXLAN 和 BGP 等多种网络模式，能够适应不同规模的集群需求。

优点

• 功能兼顾：既具备 Flannel 的简单网络功能，又支持 Calico 的网络策略。
• 适用场景广：适合那些需要简单配置但又希望支持网络策略的环境。

缺点

• 管理复杂：配置和维护相比纯粹的 Calico 或 Flannel 更加复杂。
• 资源需求高：对于一些复杂场景，可能需要更多的资源进行调优。

Kube - router：轻量级的高效网络插件

Kube - router 是一款轻量级的 CNI 插件，其设计目标是简化 Kubernetes 网络功能，同时提供高效的网络路由、负载均衡和网络策略功能。

特点

• 简化设计：旨在减少 Kubernetes 网络的复杂性，提供一个集中化的网络模型。
• BGP 路由支持：通过 BGP 进行跨节点路由配置，支持多租户的流量隔离。
• 内置负载均衡：提供了服务和 Pod 的内置负载均衡功能。

优点

• 高效功能：提供高效的路由、负载均衡和网络策略，能够满足基本的网络需求。
• 性能优越：适合简单且需要高性能的网络方案，性能表现较好。
• 路由支持：支持 BGP 路由，增强了网络的灵活性。

缺点

• 功能简化：相比于 Calico 和 Cilium，功能可能略显简化，不支持 L7 网络策略。
• 社区支持少：不如 Calico 那样被广泛使用，社区支持相对较少。

总结：插件比较

插件	特点	优点	缺点
Flannel	简单，支持多个后端（如 VXLAN）	易于部署和管理	仅支持平面网络，缺少高级网络策略
Calico	高性能，支持 BGP，强大的网络策略	高性能，支持跨云，网络策略丰富，支持 L7	配置复杂，对大规模集群较适用
Cilium	基于 eBPF，支持 L7 网络策略	极低延迟和高吞吐量，安全性强	配置较复杂，要求较高的内核版本
Weave Net	简单易用，支持加密和跨主机通信	简单易用，自动连接，支持加密通信	性能较低，适用于小规模环境
Canal	Flannel 和 Calico 的组合，提供简单的网络和网络策略	结合了 Flannel 和 Calico 的优点	配置和维护更复杂，适用于中小型集群
Kube - router	轻量级，提供路由、负载均衡、网络策略	高效的路由和负载均衡，性能较好	功能较为简化，缺少 L7 策略，社区支持较少

选择插件时的考虑因素

• • 集群规模： 对于小规模集群，Flannel 或 Weave Net 可能已经足够；对于大规模和高性能需求的集群，Calico 或 Cilium 更合适。
• • 安全性： 如果需要高级的安全功能和网络策略，建议选择 Calico 或 Cilium。
• • 网络性能： 对于要求高性能、低延迟的网络，Cilium 和 Calico（使用 BGP）是更好的选择。
• • 简单性： 如果简化配置和快速部署是您的首要目标，Flannel 或 Weave Net 可能是更好的选择。

九、简述 Helm 及其优势

Helm 是 Kubernetes 的包管理工具，类似于 Linux 系统中的 apt 或 yum，用于简化 Kubernetes 应用的安装、升级、管理和删除。它通过Helm Chart 统一定义和打包 Kubernetes 资源，使用户能够快速部署复杂的应用，提高运维效率。

Helm 的主要优势

1. 简化部署流程 🚀

   • Helm 采用 Chart（类似 Kubernetes 应用的模板包）来打包所有 Kubernetes 资源，如 Pod、Service、ConfigMap 等。
   • 用户只需执行简单的 Helm 命令，即可完成复杂应用的安装，无需手动管理多个 YAML 文件，大幅简化 Kubernetes 的部署过程。

2. 高效的版本管理 🔄

   • Helm 支持版本控制，每次部署应用时都会生成版本记录，方便回滚到任意先前的稳定版本。
   • 在应用升级出现问题时，可以快速还原到之前的版本，确保业务的连续性和稳定性。

3. 强大的依赖管理 🔗

   • 对于复杂应用，Helm 能够自动解析、安装和配置依赖项，确保所有必要的组件正确部署，减少手动管理依赖关系的复杂性。
   • 例如，一个 Web 应用可能依赖于数据库（如 MySQL），Helm 可以自动拉取并安装相应的数据库 Chart，使整体部署更加顺畅。

4. 提高可复用性 ♻️

   • Helm Chart 可在团队内部共享，也可以从开源社区（如 Artifact Hub）下载现成的 Chart，如 nginx、redis、mysql 等，避免重复造轮子，提高开发和运维效率。
   • 组织可以建立自己的 Helm Chart 仓库，标准化应用部署，提高团队协作效率。

5. 适配多环境部署 ⚙️

   • Helm 允许用户通过 values.yaml 文件自定义配置，实现不同环境（开发、测试、生产）之间的灵活适配。
   • 例如，同一套 Chart 在生产环境可以使用更高的 CPU 和内存配额，而在测试环境可以使用较低的资源配置，确保资源的合理分配。

6. 提升 DevOps 自动化能力 🤖

   • Helm 可与 GitOps 工具（如 ArgoCD、Flux）集成，实现持续部署（CD），自动同步 Git 仓库中的配置变化，大幅提升 DevOps 自动化能力。
   • 结合 CI/CD 流程，Helm 还能用于自动化应用升级，提高运维效率，降低人为操作风险。

总结

Helm 作为 Kubernetes 生态的重要工具，简化了应用部署、提供强大的版本管理和依赖管理、支持多环境适配，并能提升自动化能力，是 DevOps 和 Kubernetes 运营中的关键组件。

十、结语

在 Kubernetes 环境中，常见的 CNI 插件各有特点与优劣。Flannel 简单易用但功能相对基础；Calico 性能优越、网络策略强大但配置复杂；Cilium 基于 eBPF 技术，提供低延迟、高吞吐量及高级网络安全能力，但对内核版本有要求且配置难度大；Weave Net 简单且支持加密，但性能欠佳、网络策略功能弱；Canal 结合了 Flannel 和 Calico 的优势，不过配置和维护更复杂；Kube-router 是轻量级插件，提供高效路由等功能，但功能相比部分插件较简化，社区支持也较少。