使用Kubernetes已经快两年时间了，期间除了使用供应商提供的集群，也在开发测试环境中自建了K8S集群，一直想写一些总结，今天恰好看到一篇写心得体会的文章，勾起了记录的欲望，赶紧动手，以免又因为懒惰而错过机会。

1、关于日志

一旦使用了K8S，日志就是一个躲不开的问题，大量的日志产生，无论对于运维还是开发，都是难以避开的问题，目前生产环境中，供应商已经提供了ELK的功能，我们为了保证安全，采取了一些中间措施，保障开发也能看到日志。测试环境并没有使用ELK，毕竟ELK对于资源的占用太高了（ELK中充满了对我们团队没有实际使用的功能。这些功能是有代价的。另外，我们认为在日志中使用Elasticsearch存在固有的挑战，这使得它成为一个昂贵的日志解决方案），而是通过半手工的方式。不过据说Loki的日志功能很实用。

2、关于Jenkins

在没有找到更好的工具之前，依然建议使用Jenkins

3、操作集群没有必要

除非是为了学习原理，否则尽量把操作K8S集群的事情交给供应商（事实上，购买服务也是这个道理），我们更应该将精力用到核心业务上，毕竟，不能从操作Kubernetes中获得任何价值，你的老板需要的是你创造价值，而不是炫耀你的技术能力。

4、小CPU大内存

从我们的经验来说，K8S对于内存的要求更高，所以在请求资源的时候，尽量多些内存，这里有些小窍门。在生产环境，资源请求足够高，但不要太高，以防止在低流量时间浪费资源，并将资源限制相对接近资源请求，以便为尖峰流量提供一些喘息空间，而不会因节点内存压力而导致Pod被迫逐出。但在非生产环境，如果将CPU请求设置为零，并为容器设置足够高的CPU限制，则可以运行无限的容器。如果你的容器开始大量使用CPU，它们将被限制。然而，达到内存限制的行为与CPU不同。如果使用的内存超过了设置的内存限制，那么容器就会被杀死并重新启动。如果内存限制异常高（假设高于节点的容量），则可以继续使用内存，最终当节点的可用内存不足时，调度程序将开始逐出Pod。我们通过保持资源请求极低而限制极高，来尽可能安全地过度提交资源。在这种情况下，限制因素是内存，也就是说，无论内存请求有多低，内存限制有多高，Pod逐出，都是一个节点上所有容器使用的内存总和的函数。这段话简单的说，就是小CPU，大内存，保证Pod不会退出。

5、跨AZ的传输

最初我们曾经考虑过使用跨AZ的传输来实现热备方案，后面考虑到对于K8S的不熟悉，暂时还没有实施，但从长远看，还是要尝试一下。我们了解到，通过引入服务网格来控制从一个Pod到另一个Pod的流量是如何路由的，这是可以实现的。

以上，就是对于K8S一些实践性的总结，由于K8S也在不断的升级，学习还在持续中。。。