×

Kubernetes最佳实践

96
fengdidi
2018.04.12 20:59 字数 1488

本文翻译自Github上的arschles/kube-best-practices,原文链接:arschles/kube-best-practices

可观察性原则(Observability is golden)

Kubernetes负责编排你的Pod。如果它能够监测到Pod的如下指标,它将能够更有效地管理Pod:

  • 你的Pod需要什么:你可以通过添加Resource Limit来告诉K8S。
  • 你的Pod内部发生了什么:确保你的Pod配置了存活探针和就绪探针。
  • 同时确保你在Pod里配置了日志、监控等机制,这些机制都能够让你更清楚Pod内都发生了什么。

如果程序发生错误,请直接崩溃(When all else fails, crash)

Crash-only架构意味着你的程序遇到问题后直接崩溃而不是试着慢慢恢复自己。

Erlang语言通过引进了监管者模式推广了When all else fails, crash这个概念。监管者监管你的程序,如果你的程序崩溃了,监管者就会重启它。这种架构鼓励你的程序如果发生了错误直接崩溃即可。因为你心里有数,如果你的程序崩溃了,监管者可以马上再帮你把程序重启。

如果你的程序跑在Kubernetes上,那么Kubernetes本身就是个监管者。与其在你的程序里面写一些自我恢复的逻辑,还不如直接崩溃,让Kubernetes重启它就好了。

保证程序无序化、无状态化(Unordered is better than ordered)

不管你喜不喜欢,你的App是一个分布式系统。你不能再把你的App看成一个单一进程。所以你的App将很难处理顺序化的事件。

业界对分布式系统上的顺序化事件做了许多研究,所以如果你的业务逻辑必须依赖顺序化事件来运行的话,你需要明白分布式系统处理顺序化事件的基本方针(因果顺序关系,时间顺序关系等等),然后决定你的App使用什么顺序化事件处理策略。

或者,你也可以在你的程序里避免使用顺序化的事件,让Kubernetes自身的机制帮你处理这些。Kubernetes自身的机制可以参考以下几个文档:

去耦合(Loose coupling is better than tight coupling)

我们知道,Kubernetes会一直监控着你的App,如果环境发生了变化,它会自适应这些变化并且对你的App的部署策略做相应调整。你的App需要能够容忍这些变数。这意味着你的App需要:

  • 不能依赖某个特定的Pod
  • 通过Service或者Service Mesh与Pod通讯
  • 如果不能获取资源或者访问其他Pod,直接崩溃即可
  • 如果你需要通过Kubernetes的Api或者Kubectl查询Pod状态的话,千万不要用Pod名来检索,用Pod的Label来检索。

轻微的耦合也不一定是错的(But tight coupling isn't always wrong)

Kubernetes部署的原子组件是Pod,一个Pod可以有多个容器组成。这种设计实际上就是支持了不同容器间的轻度耦合。一个Pod内的容器要不然一起运行要不然都不运行。所以如果你的App里面有耦合组件的话,把它们部署在一个Pod里。例如:

  • Fluentd作为你App的辅助组件,与你的应用容器编排在一个Pod里,负责收集应用容器的日志。

记录你的配置(Record your configuration)

Kubernetes提供了一套声明式的API,这套API允许你告诉Kubernetes你的APP的最终状态是什么。但是你不需要告诉Kubernetes怎么达到这样的最终状态。Kubernetes自己有一套调节机制,能够将集群的状态调整到你要求的状态。
你需要时刻保证你在配置区上的代码版本是健康的、可以正常部署执行的。这样你才可以把你的程序交付给Kubernetes,在这个前提下,Kubernetes可以保证你的程序一直处于你要求的最终状态。
你可以使用Helm来管理你APP的Kubernetes版本,直接使用“helm install”将你的APP部署到Kubernetes上,这样可以保证你的APP时刻处于可用状态。

最小资源原则(Ask for the least)

类似于最小权限原则,你应该告诉Kubernetes你的APP能跑起来所需要的最小资源,剩下的富余资源交给Kubernetes来管理调度。
下面是一些你需要遵循最小资源原则的Kubernetes资源:

  • RBAC权限
  • 单一Pod里的容器数量
  • 共享的CPU资源和内存资源
  • 磁盘空间

站在巨人的肩上(Build on the shoulders of giants)

Kubernetes API帮你封装了一些很有用但是非常难实现的功能。这些功能是由一群非常聪明的人实现的,并且经过了充分的测试。尽量优先使用Kubernetes自带的这些特性,而不是试着自己在应用里去实现。
你或者可以看一下cloud native的生态系统。Cloud native上有很多高质量的框架可以在你的系统里使用。
最后,如果你在开源社区找不到符合你需求的产品,那么你可以自己构建一个,但是记得把它开源哦。
我们作为开源社区的一员,一直是本着不要重复自己(don't repeat yourself)的原则做事的。

技术随笔
Web note ad 1