对于高级工程师来说，掌握 Kubernetes 意味着要了解其复杂性、架构细节和操作挑战。以下面试问题旨在深入探究应聘者在 Kubernetes 方面的专业知识，针对高级概念、最佳实践和实际解决问题的技能。
1. 解释 Kubernetes 中控制平面组件的作用和功能。
预期答案
候选人应解释 Kubernetes 控制平面的组件，包括 kube-apiserver、etcd、kube-scheduler、kube-controller-manager 和 cloud-controller-manager。他们应详细说明这些组件如何交互以管理 Kubernetes 集群的状态，重点关注 API 服务、集群状态存储、pod 调度以及各种 Kubernetes 对象的生命周期管理等方面。
值得一提的要点：
kube-apiserver 充当控制平面的前端，公开 Kubernetes API。
etcd 是用于所有集群数据的高度可用的键值存储。
kube-scheduler 分配工作负载。
kube-controller-manager 运行控制器进程。
云控制器管理器允许您将集群链接到云提供商的 API。
您可以给出的示例
“部署新应用程序时，kube-apiserver 会处理创建请求。etcd 会存储此配置，使其成为集群所需状态的真实来源。然后，kube-scheduler 会决定在哪个节点上运行应用程序的 Pod，而 kube-controller-manager 会监督此过程以确保运行所需数量的 Pod。对于在云环境中运行的集群，cloud-controller-manager 会与云提供商交互以管理负载均衡器等资源。”
谨慎回答
“虽然这个答案概述了每个控制平面组件的核心职责，但实际功能可以超越这些基本职责，尤其是随着自定义控制器和特定于云提供商的集成的出现。此外，这些组件的管理和交互方式可能会因 Kubernetes 发行版和底层基础架构而异。”
描述设计高可用性 Kubernetes 集群的过程和注意事项。
预期答案：寻找有关在不同可用区中以多节点配置部署 Kubernetes 主服务器、利用 etcd 集群实现数据冗余以及使用负载均衡器将流量分发到 API 服务器的见解。候选人还应讨论节点健康检查和自动修复机制对确保高可用性的重要性。
值得一提的要点
多主设置以实现冗余。
跨区域的 etcd 集群可实现数据弹性。
用于 API 服务器流量分配的负载均衡器。
对工作节点进行自动化健康检查和修复。
您可以给出的示例
“在为电子商务平台设计高可用性集群时，我们在三个可用区部署了多主设置，etcd 成员分布相似以确保数据冗余。配置了 TCP 负载平衡器以将 API 请求分发到 API 服务器，确保没有单点故障。我们还使用 Kubernetes Engine 实现了节点自动修复，以自动替换不健康的节点。”
谨慎回答
“虽然这些策略显著提高了集群可用性，但它们也带来了集群管理的复杂性和潜在的成本影响。对于某些应用程序，尤其是那些可以容忍短暂停机的应用程序，如此高的冗余度可能并不划算。最佳配置通常取决于特定的应用程序要求以及成本、复杂性和可用性之间的权衡。”
如何在 Kubernetes 中实现零停机部署？
预期答案
候选人应描述滚动更新、蓝绿部署和金丝雀发布等策略。他们应该提到 Kubernetes 功能，如部署、服务和健康检查，并解释如何使用它们实现零停机更新。高级答案可能还包括使用服务网格进行更受控制的流量路由和故障注入测试。
值得一提的要点
滚动更新会逐渐用新的 Pod 替换旧的 Pod。
蓝绿部署在两个相同的环境之间切换流量。
Canary 版本逐渐向部分用户推出新版本。
健康检查确保只有健康的 Pod 才能提供流量服务。
您可以给出的示例
“对于一项关键支付服务，我们使用了金丝雀部署策略来最大限度地降低更新期间的风险。我们首先向 10% 的用户部署了一个新版本，监控错误率和性能指标。在确认稳定性后，我们使用 Kubernetes 部署来管理部署，从而逐渐增加新版本的流量，确保零停机时间。”
谨慎回答
“虽然这些策略旨在最大限度地减少停机时间，但它们的有效性可能会因应用程序架构、部署复杂性和外部依赖性而异。例如，有状态的应用程序或需要数据库迁移的应用程序可能需要 Kubernetes 原语本身无法涵盖的其他步骤。此外，网络问题或配置错误仍可能导致服务中断，这凸显了全面测试和监控的重要性。”
讨论在 Kubernetes 中管理有状态应用程序的策略。
预期答案
预期讨论的内容包括用于管理有状态应用程序的 StatefulSet、用于存储的持久卷 (PV) 和持久卷声明 (PVC) 以及用于稳定网络身份的 Headless Services。候选人还可能讨论有状态数据的备份/恢复策略以及使用操作员来自动化有状态应用程序管理。
值得一提的要点
StatefulSet 确保有序部署、扩展和删除，以及每个 Pod 唯一的网络标识符。
持久卷和持久卷声明提供了在 Pod 重启后依然有效的持久存储。
无头服务允许直接寻址 Pod，从而无需负载平衡层。
您可以给出的示例
“在部署高可用性 PostgreSQL 集群的项目中，我们使用 StatefulSets 在重新启动和重新部署时维护每个数据库 pod 的身份。每个 pod 都连接到持久卷声明，以确保数据库文件在 pod 生命周期之外持续存在。配置了无头服务来为每个 pod 提供稳定的网络身份，从而促进 PostgreSQL 集群内的对等发现。”
谨慎回答
“尽管 Kubernetes 提供了管理有状态应用程序的强大机制，但仍然会出现挑战，尤其是对于需要精确管理状态和身份的复杂有状态工作负载。例如，在管理数据库版本升级或确保副本间数据一致性时，操作复杂性可能会增加。此外，数据备份和灾难恢复策略的责任落在操作员身上，因为 Kubernetes 本身并不处理这些方面。”
解释如何优化 Kubernetes 集群中的资源使用情况。
预期答案
候选人应该谈论如何实施资源请求和限制、如何利用水平 Pod 自动缩放器以及使用 Prometheus 等工具进行监控。他们还可以提到如何使用垂直 Pod 自动缩放器和 PodDisruptionBudgets 进行更细致的资源管理并维护应用程序性能。
值得一提的要点
资源请求和限制有助于确保 Pod 被安排在具有足够资源的节点上，并防止资源争用。
Horizontal Pod Autoscaler 根据观察到的 CPU 利用率或自定义指标自动调整 pod 副本的数量。
Vertical Pod Autoscaler 推荐或自动调整请求和限制以优化资源使用情况。
Prometheus 等监控工具对于识别资源瓶颈和低效率至关重要。
您可以给出的示例
“对于流量波动的应用程序，我们根据 Prometheus 的自定义指标实施了水平 Pod 自动扩展器，目标是每个 Pod 每秒的特定请求数。这使我们能够在高峰时段自动扩展，在较安静的时段自动缩减，从而优化资源使用并保持性能。此外，我们为每个 Pod 设置资源请求和限制，以确保可预测的调度并避免资源争用。”
谨慎回答
“Kubernetes 中的资源优化高度依赖于工作负载和底层基础设施的具体特征。例如，过于激进的自动扩展可能导致快速扩展事件，从而可能破坏服务稳定性。同样，资源请求和限制的配置不当可能会导致资源利用率低下或 Pod 被驱逐。持续监控和调整对于找到正确的平衡至关重要。”
描述如何保护 Kubernetes 集群。
预期答案
寻找全面的安全策略，包括网络策略、RBAC、Pod 安全策略（或其替代品，如 OPA/Gatekeeper 或 Kyverno，考虑到 PSP 弃用）、机密管理和用于加密通信的 TLS。高级响应可能涵盖 CI/CD 管道的静态和动态分析工具、保护容器供应链和集群审计日志记录。
值得一提的要点
网络策略限制 pod 之间的流量，增强网络安全性。
RBAC 控制对 Kubernetes 资源的访问，确保只有授权用户才能执行操作。
Pod 安全策略（或现代替代方案）执行与安全相关的策略。
秘密管理对于安全处理密码和令牌等敏感数据至关重要。
实施 TLS 加密可确保传输中的数据安全。
您可以给出的示例
“为了保护处理敏感数据的集群，我们实施了 RBAC，为不同的团队成员定义明确的访问控制，确保他们只能与其角色所需的资源进行交互。我们使用网络策略来隔离应用程序的不同部分，以防止在发生违规时潜在的横向移动。对于机密管理，我们集成了一个外部机密管理器，以自动安全地将机密注入我们的应用程序。”
谨慎回答
“保护 Kubernetes 集群需要多方面的方法和持续的警惕。虽然上述策略提供了强大的安全基础，但容器化环境的动态性质和不断变化的威胁形势需要持续评估和适应。此外，这些措施的有效性可能因集群环境、应用程序架构和合规性要求而异，这凸显了制定量身定制的安全策略的必要性。”
如何保证 Kubernetes 使用的 etcd 集群的高可用性？
预期答案
预期候选人讨论将 etcd 部署为跨不同可用区域的多节点集群，为 etcd 节点使用专用硬件或实例以确保性能，实施定期快照备份，并为 etcd 健康状况设置主动监控和警报。
值得一提的要点
跨可用区域的多节点 etcd 集群可实现容错。
为 etcd 提供专用资源，以确保性能隔离。
定期快照备份用于灾难恢复。
监控和警报以主动解决问题。
您可以给出的示例
“在生产环境中，我们部署了一个三节点 etcd 集群，分布在三个不同的可用区，以确保高可用性和容错能力。每个 etcd 成员都托管在专用实例上，以提供必要的计算资源和隔离。我们每 6 小时自动进行一次快照备份，并针对指示性能问题或节点不可用的指标配置 Prometheus 警报。”
谨慎回答
“虽然这些做法显著增强了 etcd 集群的弹性和可用性，但管理 etcd 也有一定的复杂性。性能调优和灾难恢复规划需要深入的理解和经验。此外，etcd 对网络延迟和磁盘 I/O 性能的敏感性意味着，即使采取这些措施，实现最佳性能也可能需要持续的调整和基础设施投资。”
讨论服务网格在 Kubernetes 中的作用。
预期答案
候选人应解释服务网格如何为微服务通信提供可观察性、可靠性和安全性。他们可能会讨论 Istio 或 Linkerd 等特定服务网格，并描述流量管理、服务发现、负载平衡、mTLS 和断路等功能。
值得一提的要点
增强了对微服务交互的可观察性。
金丝雀部署和 A/B 测试的流量管理功能。
mTLS 用于安全的服务到服务通信。
弹性模式，如断路器和重试。
您可以给出的示例
“对于面临复杂的服务间通信和可靠性挑战的微服务架构，我们实施了 Istio 作为我们的服务网格。它允许我们引入金丝雀部署，逐步将流量转移到新版本并监控问题。Istio 的 mTLS 功能还帮助我们在不修改服务代码的情况下确保通信安全。此外，我们利用 Istio 的可观察性工具来深入了解服务依赖关系和性能。”
谨慎回答
“尽管服务网格在安全性、可观察性和可靠性方面增加了重要价值，但它们也为 Kubernetes 环境带来了额外的复杂性和开销。使用服务网格的决定应该与应用程序架构的当前和未来复杂性以及团队管理这种复杂性的能力相平衡。此外，对于更简单的应用程序或 Kubernetes 内置功能就足够的环境来说，服务网格的好处可能有点过头了。”
如何进行 Kubernetes 集群的容量规划？
预期答案
答案应包括使用指标和日志监控当前使用情况、根据趋势或即将开展的项目预测未来需求以及考虑 Kubernetes 组件的开销。他们还应该讨论用于扩展集群和应用程序的工具和实践。
值得一提的要点
利用 Prometheus 等监控工具收集使用情况指标。
分析历史数据以预测未来的资源需求。
在容量规划中考虑集群组件的开销。
为节点和 pod 实现自动扩展策略。
您可以给出的示例
“在为在线零售应用程序预期的用户流量激增做准备时，我们分析了历史 Prometheus 指标，以确定峰值使用模式并预测未来需求。然后，我们提前增加了集群容量，同时为前端服务配置了水平 Pod 自动缩放器，以便根据需求动态扩展。此外，我们启用了 Cluster Autoscaler 来根据整体集群资源利用率添加或删除节点，确保我们能够有效满足用户需求。”
谨慎回答
“Kubernetes 中的容量规划需要在确保峰值负载的足够资源与避免导致不必要成本的过度配置之间取得平衡。预测分析可以指导容量调整，但不可预见的事件或需求的突然激增仍然会对即使是最完善规划的环境构成挑战。持续的监控和调整，结合响应式扩展策略，对于有效应对这些挑战至关重要。”
解释 Kubernetes 的 GitOps 概念和好处。
预期答案
寻找有关 GitOps 如何使用 Git 存储库作为声明性基础架构和应用程序的真实来源的解释。好处包括提高部署的可预测性、更容易回滚、增强安全性和更好的合规性。他们可能会提到 Argo CD 或 Flux 等特定工具。
值得一提的要点
GitOps 利用 Git 作为系统和应用程序配置的单一真实来源，支持版本控制、协作和审计跟踪。
自动同步和部署过程确保 Kubernetes 集群的状态与 Git 中存储的配置相匹配。
通过拉取请求审查和自动检查简化回滚到以前的配置并增强安全性。
您可以给出的示例
“在最近的一个简化部署流程的项目中，我们使用 Argo CD 采用了 GitOps 工作流。我们将所有 Kubernetes 部署清单存储在 Git 存储库中。Argo CD 持续将集群状态与存储库同步。当我们需要更新应用程序时，我们只需在 Git 中更新其清单并合并更改即可。Argo CD 会自动将更新应用于集群。这不仅简化了我们的部署流程，还为更改提供了清晰的审计跟踪并简化了回滚。”
谨慎回答
“虽然 GitOps 在自动化、安全性和可审计性方面提供了许多好处，但其有效性在很大程度上取决于组织在 CI/CD 实践方面的成熟度以及开发人员对 Git 工作流程的熟悉程度。此外，对于复杂的部署，在声明式管理配置方面可能会有一个学习曲线。它还需要为 Git 存储库制定可靠的备份策略，因为它会成为关键的故障点。”
如何在大规模 Kubernetes 环境中处理日志记录和监控？
预期答案
候选人应谈论用于聚合来自多个来源的日志的集中式日志解决方案（例如 ELK stack、Loki）以及用于跟踪集群和应用程序的运行状况和性能的监控工具（例如 Prometheus、Grafana）。高级答案可能包括实施自定义指标和警报。
值得一提的要点
集中式日志记录支持聚合、搜索和分析 Kubernetes 集群内所有组件和应用程序的日志。
使用 Prometheus 进行监控并使用 Grafana 进行可视化可以深入了解应用程序性能和集群健康状况。
根据特定指标设置警报以主动解决问题的重要性。
您可以给出的示例
“对于大型电子商务平台，我们实施了 ELK 堆栈以进行集中日志记录，汇总来自所有服务的日志以便于访问和分析。我们使用 Prometheus 监控我们的 Kubernetes 集群和服务，并使用 Grafana 仪表板实时可视化关键性能指标。我们为关键阈值（例如高 CPU 或内存使用率）设置了警报，使我们能够在潜在问题影响客户之前快速识别和缓解这些问题。”
谨慎回答
“在大规模 Kubernetes 环境中实施全面的日志记录和监控至关重要，但会带来复杂性和开销，尤其是在资源消耗和管理方面。微调要收集的指标和要保留的日志对于平衡可见性和运营效率至关重要。此外，监控和日志记录系统的有效性取决于正确的配置和定期维护，以适应不断发展的应用程序和基础设施环境。”
描述如何在 Kubernetes 中实现网络策略及其影响。
预期答案
考生应解释如何使用网络策略来定义 Kubernetes 集群内 Pod 到 Pod 通信的规则，从而增强安全性。他们可能会解释 Kubernetes 中的默认宽容网络以及网络策略如何限制流量，并引用使用 YAML 定义的示例。
值得一提的要点
网络策略允许管理员在 IP 地址或端口级别控制流量，从而增强集群安全性。
它们由 Kubernetes 网络插件实现，并且需要支持网络策略的网络提供商。
有效使用网络策略可以显著降低集群内未经授权的访问或违规的风险。
您可以给出的示例
“为了隔离并保护后端服务免受公共互联网访问的影响，我们定义了仅允许来自特定前端 pod 的流量的网络策略。以下是一个示例策略，该策略将进入后端 pod 的流量限制为仅来自带有标签的 pod role: frontend：
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: backend-access-policy
spec:
podSelector:
matchLabels:
app: backend
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
此策略确保只有前端 pod 可以与后端通信，从而大大增强了我们服务的安全态势。”
谨慎回答
“虽然网络策略是保护 Kubernetes 集群内流量的强大工具，但其有效性取决于策略的正确和全面定义。配置错误的策略可能会无意中阻止关键通信或留下漏洞。此外，不同网络提供商之间的网络策略实施和行为可能有所不同，因此需要进行彻底的测试和验证，以确保策略在您的特定环境中按预期运行。”
评论区