使用Kubernetes最常见的十个错误（上）
极客时间编辑部
讲述：丁婵大小：8.98M时长：06:33
你好，欢迎收听极客视点。
最近，工程师马雷克·巴蒂克（Marek Bartik）称他使用 kubernetes 多年，见过的集群不计其数，还见识了很多经常重复出现的错误，其中大部分错误他和他的同事也犯过。因此他总结了一些使用 Kubernetes 最常见的错误以及应对错误的方法，InfoQ 对其进行了翻译，供你参考。
1. 资源：请求和限制
人们经常不设置 CPU 请求或将 CPU 请求设置得过低，这样就可以在每个节点上容纳很多 Pod，结果节点就会过量使用（overcommited）。在需求较高时，节点的 CPU 全负荷运行，而负载只能得到“它所请求的”数据，使 CPU 节流（throttled），从而导致应用程序延迟和超时等指标增加。
另一方面，启用 CPU 限制可能会在节点的 CPU 没有充分利用的情况下，对 Pod 进行不必要的节流，这也会导致延迟增加。人们也讨论过关于 Linux 内核中的 CPU CFS 配额和因为设置了 CPU 限制并关闭 CFS 配额而导致的 CPU 节流问题。CPU 限制造成的问题可能会比它能解决的问题还多。
内存过量使用会给你带来更多麻烦，达到 CPU 限制将导致节流，达到内存限制会导致 Pod 被杀。想要尽量减少这类状况就不要过量使用内存，并使用 Guaranteed QoS（Quality of Service）将内存请求设置为与限制相等，
2. liveness 和 readiness 探针
默认情况下，Kubernetes 不会指定任何 liveness 和 readiness 探针。但如果出现不可恢复的错误，你的服务将如何重新启动呢？负载均衡器如何知道特定的 Pod 可以开始处理流量，或能处理更多流量呢？
人们通常不知道这两者间的区别。
如果探针失败，liveness 探针将重新启动 Pod；
Readiness 探针失败时，会断开故障 Pod 与 Kubernetes 服务的连接（你可以用 kubectl get endpoints 检查这一点），并且直到该探针恢复正常之前，不会向该 Pod 发送任何流量。
人们通常认为，readiness 探针只在开始时运行，以判断 Pod 何时 Ready 并可以开始处理流量，但这只是它的一个用例而已。
它的另一个用例是在一个 Pod 的生命周期中判断它是否因过热而无法处理太多流量或一项昂贵的计算，这样你就会先让它冷却下来，等到 readiness 探针成功，你会再给它发送更多流量。在这种情况下，也就是当 readiness 探针失败时，如果 liveness 探针也失败就会非常影响效率了。
3. 在所有 HTTP 服务上启用负载均衡器
你的集群中可能有很多 HTTP 服务，并且你希望将这些服务对外界公开。
如果你将 Kubernetes 服务以 type: LoadBalancer 的形式公开，那么它的控制器（取决于供应商）将提供并协调一个外部负载均衡器，当你创建很多这种资源时，它们可能会变得很昂贵。
在这种情况下，共享同一个外部负载均衡器可能会更好些，这时你将服务以 type: NodePort 的形式公开。或者更好的方法是部署 nginx-ingress-controller（或 traefik）之类的东西，作为公开给这个外部负载均衡器的单个 NodePort 端点，并基于 Kubernetes ingress 资源在集群中路由流量。
其他相互通信的集群内（微）服务可以通过 ClusterIP 服务和开箱即用的 DNS 服务发现进行通信。注意不要使用它们的公共 DNS/IP，因为这可能会影响它们的延迟和云成本。
4. 无 Kubernetes 感知的集群自动缩放
在集群中添加节点或删除节点时，不应该考虑一些简单的度量指标，比如这些节点的 CPU 利用率。在调度 Pod 时，你需要根据许多调度约束来进行决策，比如 Pod 和节点的亲密关系（affinities）、污点（taints）和容忍（tolerations）、资源请求（resource requests）、QoS 等。让一个不了解这些约束的外部自动缩放器（autoscaler）来处理缩放可能会招来麻烦。
假设有一个新的 Pod 要被调度，但是所有可用的 CPU 都被请求了，并且 Pod 卡在了 Pending 状态。可是外部自动缩放器会查看当前的平均 CPU 使用率，然后决定不扩容（不添加新的节点），结果 Pod 也不会被调度。
缩容总是更难一些。假设你有一个有状态的 Pod，就是连接了持久卷，由于持久卷（persistent volumes）通常是属于特定可用区域的资源，并且没有在该区域中复制，你自定义的自动缩放器会删除一个带有此 Pod 的节点，而调度器无法将其调度到另一个节点上，因为这个 Pod 只能待在持久磁盘所在的那个可用区域里。Pod 将再次陷入 Pending 状态。
社区正在广泛使用 cluster-autoscaler ，它运行在集群中，能与大多数主要的公共云供应商 API 集成；它可以理解所有这些约束，并能在上述情况下扩容。它还能搞清楚是否可以在不影响你设置的任何约束的前提下优雅地缩容，从而节省你的计算成本。
5. 不要使用 IAM/RBAC 的能力
不要使用 IAM Users 永久存储机器和应用程序的秘钥，而要使用角色和服务帐户生成的临时秘钥。
另外，当服务帐户或实例配置文件不需要 admin 和 cluster-admin 权限时，也不要给它们这些权限。这有点困难，尤其是在 k8s RBAC 中，但仍然值得一试。
以上是使用 Kubernetes 最常见错误的其中 5 个，受篇幅所限，下文继续分享其余 5 个常见错误，欢迎持续关注。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论