配置最佳实践

定义配置文件的时候，指定最新的稳定API版本（目前是V1）。
使用YAML格式而不是JSON格式的配置文件。在大多数场景下它们都可以作为数据交换格式，但是YAML格式比起JSON更易读和配置。
尽量将相关的对象放在同一个配置文件里。这样比分成多个文件更容易管理。
为了简化和最小化配置，也为了防止错误发生，不要指定不必要的默认配置。例如，省略掉的selector和label，如果你希望它们跟podTemplate中的label一样的话，因为那些配置默认是podTemplate的label产生的。
将资源对象的描述放在一个annotation中可以更好的内省。

裸的Pods vs Replication Controllers和 Jobs

如果有其他方式替代“裸的“ pod（如没有绑定到上的pod），那么就使用其他选择。在node节点出现故障时，裸奔的pod不会被重新调度。Replication Controller总是会重新创建pod，除了明确指定了restartPolicy: Never 的场景。也许是比较合适的选择。

通常最好在创建相关的replication controllers之前先创建，你也可以在创建Replication Controller的时候不指定replica数量（默认是1），创建service后，在通过Replication Controller来扩容。这样可以在扩容很多个replica之前先确认pod是正常的。
除非十分必要的情况下（如运行一个node daemon），不要使用hostPort（用来指定暴露在主机上的端口号）。当你给Pod绑定了一个hostPort，该pod可被调度到的主机的受限了，因为端口冲突。如果是为了调试目的来通过端口访问的话，你可以使用 kubectl proxy and apiserver proxy 或者。你可使用 Service 来对外暴露服务。如果你确实需要将pod的端口暴露到主机上，考虑使用 service。
跟hostPort一样的原因，避免使用 hostNetwork。

定义来指定应用或Deployment的 semantic attributes 。例如，不是将label附加到一组pod来显式表示某些服务（例如，service:myservice），或者显式地表示管理pod的replication controller（例如，controller:mycontroller），附加label应该是标示语义属性的标签，例如{app:myapp,tier:frontend,phase:test,deployment:v3}。这将允许您选择适合上下文的对象组——例如，所有的”tier:frontend“pod的服务或app是“myapp”的所有“测试”阶段组件。

可以通过简单地从其service的选择器中省略特定于发行版本的标签，而不是更新服务的选择器来完全匹配replication controller的选择器，来实现跨越多个部署的服务，例如滚动更新。
注意 Deployment 对象不需要再管理 replication controller 的版本名。Deployment 中描述了对象的期望状态，如果对spec的更改被应用了话，Deployment controller 会以控制的速率来更改实际状态到期望状态。（Deployment目前是的一部分）。
利用label做调试。因为Kubernetes replication controller和service使用label来匹配pods，这允许你通过移除pod中的label的方式将其从一个controller或者service中移除，原来的controller会创建一个新的pod来取代移除的pod。这是一个很有用的方式，帮你在一个隔离的环境中调试之前的“活着的” pod。查看 kubectl label 命令。

如果你没有将镜像标签指定为:latest，例如指定为myimage:v1，当该标签的镜像进行了更新，kubelet也不会拉取该镜像。你可以在每次镜像更新后都生成一个新的tag（例如myimage:v2），在配置文件中明确指定该版本。

注意： 在生产环境下部署容器应该尽量避免使用:latest标签，因为这样很难追溯到底运行的是哪个版本的容器和回滚。