从多个方面总结Kubernetes配置最佳实践
１.普通配置
- 当定义配置时，使用最新的稳定版API，对于非稳定版注意后续更新。
- 利用版本控制器管理配置文件，有利于变更审计、审核、回滚、配置重复利用。
- 使用对用户更友好的YAML格式写配置文件。
- 考虑将密切耦合的相关对象写入一个配置文件，管理一个文件比管理多个文件更方便。
- kubectl某些命令支持目录，考虑将相关文件置入同一目录。
- 如果没打算修改默认值，不要明确指定。这样配置文件更小，并且如果后续版本修改默认值的话，升级更方便。
- 在对象的注解中加入描述性信息。
２.裸pod与ReplicSet、Deployment、Job
- 不要直接单独使用pod，因为裸pod不会被控制器调度、不会根据重启策略重新启动。对于不需要重新启动的pod考虑使用Job，仍然接受调度但不会再被重新启动。
３.服务
- 在创建、访问后端如ReplicaSet、Deployment之前，先创建service。在旧版本Kubernetes中，当启动容器时，系统将所有可用service通过环境变量的形式传递给容器，以供容器访问这些资源，这么做的目的是向前兼容旧版本。在新版本中，不要使用环境变量访问外部服务，而应该使用DNS服务发现功能。
- 如无必要，不要为pod指定hostPort，就是pod不要占用宿主机端口。这么做会使pod与宿主机耦合太紧，影响pod在node之间的调度，因为要保证宿主机上的端口还没有被占用。如果是出于调试目的需要直接访问pod，可以使用apiServer proxy或者kubectl port-forward功能，这两个功能允许用户通过pod名称直接访问pod，它们提供的是中间代理功能。如果pod确实需要占用hostPort，优先考虑 NodePort。
- 避免使用主机网络，原因同上，要降低耦合性。
- 如不想使用kube-proxy服务发现功能，考虑使用无头服务。
４.标签
- 标签是Kubernetes中组织管理资源的重要手段，合理的将对象语义属性添加到标签中，如{ app: myapp, tier: frontend, phase: test, deployment: v3 }等，有得于对象的组织管理。
- 利用标签实现灰度发度、金丝雀部署等。利用标签将pod从副本控制器中隔离出来单独调试。
5.容器镜像
- 容器镜像的默认拉取规则imagePullPolicy=IfNotPresent，只要镜像已经存在就不会再拉取，这可能导致使用镜像不是最新版本，可以将其改成imagePullPolicy=Always，每次启动容器都重新拉取镜像。可也以为镜像指定:latest标签，则拉取规则默认是Always，此特性可能会被废弃，不建议使用，并且latest不是明确的版本号，不容易审查某个历史pod使用的究竟是那个版本的image。
- 为了保证某个pod只使用某个版本的image，在拉取镜像时可以为其指定数字摘要，如sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2，摘要能保证image的唯一性、不变性。
６.kubectl命令
- 多利用kubectl命令如kubectl create、kubectl apply等命令对目录的支持，目录下的配置文件统一使用yaml格式。
- 对于kubectl get、kubectl delete等使用，用标签选择器代替对象名称提供操作效率及命令的可重用性。
- 用kubectl run、kubectl expose命令运行简单、调试性对象。
参考：https://kubernetes.io/docs/concepts/configuration/overview/
其中有一个很好的最佳实践的参考示例