国外网站404错误页,网站地址搜索,简单的手机网址大全,天堂网长尾关键词挖掘网站Kubernetes 作为大规模企业级应用容器编排的首推工具#xff0c;其为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能#xff0c;本文作者 Marek Bartik 深入分享了 K8s 的避坑宝典#xff0c;相信会对开发者们大有裨益。作者 | Marek Bartik… Kubernetes 作为大规模企业级应用容器编排的首推工具其为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能本文作者 Marek Bartik 深入分享了 K8s 的避坑宝典相信会对开发者们大有裨益。作者 | Marek Bartik已获作者翻译授权译者 | 苏本如责编 | 唐小引头图 | CSDN 下载自 VCG出品 | CSDNIDCSDNnews在我们多年使用 Kubernetes以下简称为 K8s的经历中我们有机会近距离接触了相当多的集群包括依托于 GCP、AWS 和 Azure 上的托管和非托管集群并且看到一些错误在不断重复。但不必为此感到羞耻因为我们也犯了很多这样的错误接下来我会尽量解释那些我们经常犯的错误并讨论如何修复它们。资源 —— 请求Request和限制Limit的设置这无疑是最值得关注的因而列在了这个错误榜单的第一位。设置 CPU request 的常见错误有两种 —— 「不设置」或「设置得很低」这样我们可以在每个节点上容纳更多的 pod这两种错误会导致节点被过量使用。在高需求的时候节点的 CPU 就会被完全占用我们的工作负载就只能得到“它所请求的很低的资源”因此工作负载得到的 CPU 资源就很有限这样就会导致应用程序延迟、超时等问题的增加。不设置 CPU requestBestEffort应尽量避免时的配置如下 resources: {}CPU request 设置得很低(应尽量避免时的配置如下 resources:requests:cpu: 1m另一方面设置一个 CPU limit 值可能会不必要地限制 pod 对 CPU 的使用即使节点的 CPU 没有被充分利用时这同样会导致延迟问题的增加。对于使用 Linux 内核中的 CPU CFS quota 来控制对 CPU 的使用或关闭 CPU CFS quota 并用 CPU limit 设置来代替这两种方式到底孰优孰劣有一个公开的讨论结论是 CPU limit 这个设置可能会导致更多的问题。内存的过量使用会给你带来更多的麻烦。达到 CPU limit 时只会导致 CPU 使用受限达到 Memory limit 将会导致 Pod 被杀死。你听说过 OOMkill 吗是的它正是我们要说的内存不足时自动杀死进程的机制。如果你想尽量减少这种情况的发生那就不要过度使用内存而应该使用“Guaranteed QoS”模式将 Memory Request 值设为等于 Memory limit 值就像下面的示例一样。关于这个话题你可以从 Henning JacobsZalando的这个演讲中获得更多信息[1]。Burstable QoS 模式下的资源设置很可能导致 OOMKill 机制更频繁地被触发 resources:requests:memory: 128Micpu: 500mlimits:memory: 256Micpu: 2Guaranteed QoS 模式的资源设置 resources:requests:memory: 128Micpu: 2limits:memory: 128Micpu: 2那么在你设置 resource 时有什么工具可以帮助你呢你可以借助 metrics-server 来检查 pod和其中的容器当前的 CPU 和内存的使用情况。很有可能它已经在服务器端运行了。要想看到使用情况你只需简单地运行以下命令kubectl top pods
kubectl top pods --containers
kubectl top nodes不过这些命令只能显示当前的使用情况。这对于大致地了解资源使用情况是足够了但最终你希望能够及时查看一些使用指标比如CPU 峰值、昨天上午的 CPU 使用情况等指标。在这个方面Prometheus、DataDog 和许多其他的监控系统可以帮助你。它们从 metrics-server 上获取这些指标信息并存储起来然后你就可以对其进行查询和绘制图形。VerticalPodAutoscaler[2] 工具可以帮助你自动化这一手动过程包括及时查看 CPU/内存的使用情况以及基于使用情况设置新的 request 和 limit 的值。高效地利用你的计算资源并非易事。就像一直在玩俄罗斯方块。如果发现自己在平均利用率很低例如〜10的情况下为计算支付了大量费用那么你可能需要看看基于 AWS Fargate 或 Virtual Kubelet 之类的产品是否能解决你的问题这些产品更多地利用了无服务器/按使用付费的计费模式这对你来说可能更便宜。存活liveness探针和就绪readiness探针的设置默认情况下系统不会设置检测一个 pod 状态的存活探针和就绪探针。K8s 的自愈能力有时可以让容器一直工作下去……但是如果容器出现了不可恢复的错误你的服务将如何重新启动呢负载均衡器loadbalancer如何判断某个特定的 Pod 是否可以开始处理流量或者是否可以继续处理更多流量通常人们不知道这两个探针liveness 和 readiness之间的区别。如果对一个 pod 的 liveness 探测失败就会重启这个 pod。如果对一个 pod 的 readiness 探测失败就会将这个 pod 和 K8s 服务断开连接你可以使用 kubectl get endpoints 命令进行检查并且在该探测再次成功之前不再向其发送任何流量。注意这两种探测需要在整个 pod 的生命周期内都运行。这点很重要。人们常常认为readiness 探测仅在容器起动时运行以告知 K8s 服务 pod 何时就绪并且可以开始为流量提供服务。但这只是它的一个应用场景。另外一个应用场景是在一个 pod 的生命周期内使用 readiness 探测可以让系统知道一个 pod 是否变得太“热”而无法处理过多的流量或昂贵的计算以便系统停止向它发送更多的流量而让它“冷静”下来。直到 readiness 再次探测成功系统才开始继续向它发送更多流量。在这种情况下当 pod 过热导致 readiness 探测失败时如果让 liveness 探测失败就不是我们想要的。因为我们为什么要重启一个运行良好并且正在处理大量工作的 Pod 呢有时候不配置任何一个探针比错误地配置探针要好。如上所述如果将 liveness 探针配置成和 readiness 探针一样那么你将遇到大麻烦。作为开始建议你仅仅配置 readiness 探针因为 liveness 探针很危险。如果一个和其它 pod 有共享依赖项的 pod 被关闭那么你必须保证针对这个 pod 的任何一个探针都不能失败否则将导致所有 Pod 的级联失败。那你就是在搬起石头砸自己的脚了。用于 HTTP 服务的负载均衡器你的集群中可能有很多你想对外开放的 HTTP 服务。如果你把 K8s 的外部访问方式设置为 LoadBalancer 类型则其控制器特定于供应商将被配置来支持一个外部负载均衡器不一定非得是支持七层交换的 L7 负载均衡器更可能是仅仅支持四层交换的 L4 负载均衡器并且这些资源外部静态 IPv4 地址、计算硬件、带宽等等可能会变得很昂贵因为你会创建许多这样的服务。在这种情况下共享一个外部负载均衡器可能更有意义并且你可以将 K8s 的外部访问方式设置为 NodePort 类型。或者更好的方法是部署一个像 nginx-ingress-controller或者 traefik之类的东西作为暴露给外部负载均衡器的单个 NodePort endpoint并基于 K8s ingress resource 配置在集群中分配并路由流量。集群内的其他需要会话的微服务可以通过 ClusterIP 服务和 K8s 自带的 DNS 服务发现DNS Service Discovery来实现会话。注意不要使用公共 DNS / IP因为这可能会导致延迟和云使用成本的增加。非 K8s 感知的集群自动伸缩在集群中添加节点或者从集群中删除节点时你不应该只是考虑一些简单的指标如节点的 CPU 利用率。在调度 Pod 时你需要根据很多调度约束条件如 Pod 和节点的亲和性污点和容忍资源请求QoS 等等来进行决策。如果一个外部自动伸缩器不能理解这些约束可能会带来很大的麻烦。假设一个新的 pod 要被调度但是所有可用的 CPU 都被占用了而且这个 pod 现在处于挂起状态。当外部自动伸缩器看到当前使用的平均 CPU 情况非常高就不会向外扩展了将这个 pod 添加作为节点。也就是说这个 pod 不会被调度。向内收缩从集群中删除节点总是更加困难。假设你有一个有状态的 pod连接了持久化存储卷由于持久化存储卷这种资源通常属于某个特定的可用区域并且不能在该区域中复制当你的自定义自动伸缩器删除一个带有此 pod 的节点时调度器无法将其调度到另一个节点上因为它受到持久化存储卷属于唯一可用区域的限制。所以这个 Pod 再次被卡在挂起状态。K8s 社区正在广泛使用 cluster-autoscaler 集群自动伸缩器它运行在你的集群中并且已经和大多数主要的公共云提供商的 API 实现了集成理解所有这些约束可以帮助你在上述情况下实现自动向外扩展。它还能够帮助你确定在不影响设置的约束条件下方便地实现自动向内收缩以节省你的计算成本。不使用 IAM/RBAC 能力不要将 IAM User 与机器和应用程序的永久 secret 一起使用而应该使用角色role和服务账户(service account)生成临时 secret。我们经常看到这样错误的用法将访问权限和 secret key 硬编码到应用程序的配置中当使用云 IAM 时从来不轮换 secret。在合适的情况下你应当使用 IAM 角色(role)和服务帐户(service account)而不是 IAM Users。跳过 kube2am直接用于服务帐户的 IAM 角色。就像 Štěpán Vraný 在这篇博客文章[3]中所说的那样。apiVersion: v1
kind: ServiceAccount
metadata:annotations:eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-rolename: my-serviceaccountnamespace: default上面的示例不是很难理解不是吗另外在不是必要时千万不要将 admin 和 cluster-admin 的权限给予服务帐户或实例配置文件。这点做起来有点困难尤其是在使用 K8s 的 RBAC 时但是仍然值得努力。POD 的自我反亲和性运行某个部署的 pod 副本比如说有 3 个 pod 副本当节点下线时你发现所有副本都随之同时下线了。呵呵所有副本竟然都是在一个节点上运行的吗K8s 难道不应该有魔法可以自动提供高可用性吗你不能指望 K8s 调度器自动为你的 pod 强加一个反亲和性设置。相反你应该明确地定义它们如下例。// omitted for brevitylabels:app: zk
// omitted for brevityaffinity:podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: Invalues:- zktopologyKey: kubernetes.io/hostname你需要像上面这样设置 pod 的反亲和性它将确保 pod 被调度到不同的节点上注意这个设置是在调度时检查而不是在执行时检查因此需要设置成 requiredDuringSchedulingIgnoredDuringExecution 类型。我们这里讨论的是在不同节点这里是 topologyKey: kubernetes.io/hostname上的 pod 反亲和性podAntiAffinity而不是不同可用区域的 pod 反亲和性。如果你真的需要高可用性你应该更加深入地探讨这个话题。没有 poddisruptionbudget你是在 K8s 上运行生产环境的工作负载。你的节点和集群必须不时地升级或停用。而 PodDisruptionBudgetpdb就是一种被集群管理员和集群用户广泛用来确保服务质量的 API。请确保你创建了 pdb以避免由于节点停用过多而导致不必要的服务中断。apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:name: zk-pdb
spec:minAvailable: 2selector:matchLabels:app: zookeeper作为集群用户你可以这样告诉集群管理员“嘿我这里有个 zookeeper 服务不管你想做什么我希望至少保证两个副本始终可用。”关于这个话题我在这篇博文中作了深入地讨论[4]。共享集群中有更多租户或环境K8s 命名空间不提供任何强隔离。人们似乎期望如果将非生产环境工作负载分离到一个命名空间将生产环境工作负载分离到另一个命名空间那么一个工作负载就永远不会影响另一个工作负载这样就可以实现某种程度的公平性基于资源请求和限制、配额、优先级类和隔离性基于亲和性、容忍度、污点或节点选择器以便“物理地”分离数据平面(data plane)中的工作负载但是实现这种程度地分离相当复杂。如果你需要在同一集群中同时拥有这两种类型的工作负载那么你将不得不承受这种复杂性。但是如果你不是非要这样做不可并且拥有另一个集群对你来说相对便宜比如在公共云中那么最好将它们放在不同的集群中以实现更高的隔离级别。设置 externalTrafficPolicy 值为 Cluster经常看到这种情况所有的流量在集群内全部被路由到一个 NodePort 服务 K8s 服务默认将 externalTrafficPolicy:的值设为 Cluster即 externalTrafficPolicy: Cluster。这意味着集群内的每个节点都打开该 NodePort 服务这样你就可以使用任何一个节点和所需的服务一组 pods通信。通常负责提供 NodePort 服务的实际 pod 只在这些节点的子集上运行。这意味着如果你与一个没有运行 pod 的节点会话它会将流量转发到另一个节点从而导致额外的网络跳数和延迟的增加如果节点位于不同的 AZ 或不同的数据中心则延迟可能会变得非常高并且给它带来额外的出口egress成本。将 K8s 服务的 externalTrafficPolicy 值设置为 Local 即 externalTrafficPolicy: Local将不会导致在每个节点上打开该 NodePort 服务它只会在 pod 实际运行的节点上打开。如果你使用一个能够对 endpoint 进行状态检查的外部负载平衡器如 AWS ELB 所做的它就仅仅将流量发送到它应该发送到的节点从而改进延迟、降低计算开销和出口成本并提高健全性。很可能你会将像 traefik 或 nginx-ingress-controller 之类的服务公开为 NodePort 类型或者 LoadBalancer它也使用 NodePort以便路由 http ingress 流量这个设置可以大大减少此类请求的延迟。这里有篇很棒的博客文章[5]深入探讨了 externalTrafficPolicy 各种设置以及它们的优点和缺点。有状态pet集群以及过高地控制平面的压力你从按名字调用你的服务器 Anton, HAL9000 和 Colossus到为你的 K8s 节点生成随机 id现在你开始按名字来调用集群了你知道你是如何开始使用 K8s 进行概念验证的你将集群命名为“testing”并且在生产环境中仍然使用这个名字(testing)。这样命名导致了每个人都害怕碰它吗这个故事真实发生过Pet 集群有状态的集群并不容易管理你可能需要考虑不时地删除你的集群练习灾难恢复并管理好控制平面control plane。害怕操作控制平面不是个好现象。Etcd 组件挂起好吧你有个大麻烦。另一方面对控制平面操作太多也不好。随着时间的推移控制平面会越来越慢可能的原因是你要么创建了太多对象而不轮换其状态这在使用默认设置的 helm 时非常常见它将导致在 configmaps/secrets 中不轮换其状态最终在控制平面中有数千个对象要么不断地从 kube-api 中拚凑并编辑了大量内容用于自动伸缩、cicd、监控事件、事件和控制器的日志等等。另外请查看你的 K8s 托管服务提供商承诺的 SLA/SLO 以及服务质量保障。你的提供商可能会保证控制平面或其子组件的可用性但不会保证让你满意的 p99 延迟。也就是说你运行 kubectl get nodes 命令只要该命令在 10 分钟执行完成并返回正确结果你的服务提供商就仍然没有违反服务保证。附送一个问题使用 latest 标签这是一个经典的问题。但是最近我发现自己不经常看到这种问题了可能因为我们太多人都在这上面栽过跟头所以我们不再使用:latest 这个标签了。AWS ECR 现在支持标签不变性这个很棒的特性绝对值得你去查看。总结不要指望一切都会自动进行K8s 并非灵丹妙药。一个糟糕的应用程序始终是糟糕的应用程序即使在 K8s 上也改变不了实际上可能甚至更糟糕。稍不小心你可能就会面对诸如太多复杂性过高的压力控制平面缓慢没有灾难恢复策略等麻烦。不要对开箱即用的多租户设计和高可用性期望过高。花点时间思考如何让你的云应用成为原生应用。查看 Henning 收集的这些关于 K8s 使用的失败故事[6]可以对你在将来避开这些错误有所帮助。如果你看到有人在 K8s 使用上犯了不同于本文中的错误请在 Twitter 上告诉我们MarekBartik MstrsObserver[1] Optimizing Kubernetes Resource Requests/Limits for Cost-Efficiency and Latency - Highload, https://www.slideshare.net/try_except_/optimizing-kubernetes-resource-requestslimits-for-costefficiency-and-latency-highload[2] https://cloud.google.com/kubernetes-engine/docs/concepts/verticalpodautoscaler[3] https://blog.pipetail.io/posts/2020-04-13-more-eks-tips/[4] https://blog.marekbartik.com/posts/2018-06-29_kubernetes-in-production-poddisruptionbudget/[5] https://www.asykim.com/blog/deep-dive-into-kubernetes-external-traffic-policies[6] https://k8s.af/【作者自我简介】Marek Bartik一名 NoOps/NoCode 的坚定支持者。在攻读“计算机系统和网络”硕士学位时开始从事 C编程工作。在 SysAdmin 年代长大的我很快意识到沟通和协作的重要性。现在我专注于云架构、微服务和 Continuous Everything 来解决业务问题而非技术问题。我热爱旅行并且是极简主义DevOps 和云原生的大力倡导者。英文10 most common mistakes using Kubernetes链接https://blog.pipetail.io/posts/2020-05-04-most-common-mistakes-k8s/作者Marek Bartik翻译苏本如责编唐小引【END】推荐阅读一文带你从头认识什么是「缓存」在 520 这天竟然有人把 Docker讲清楚了 | 原力计划如何使用 SQL Server FILESTREAM 存储非结构化数据这篇文章告诉你平安科技王健宗所有 AI 前沿技术都可以在联邦学习中大展身手踢翻这碗狗粮程序员花 7 个月敲出 eBay只因女票喜欢糖果盒又一年5.20用Python助力程序员脱单大攻略视频版斗地主吗能学区块链那种 | 原力计划真香朕在看了
