正文
labels:
system: jdos-sys
app: jdos-app
group: jdos-group-01
env: test
region: china
groupconfig: 1115fa3e-8a6c-409f-afea-e2f007da2b0e
name: jdos-pod-name
lb
-status: active
system/app/group 用以标识其管理层级，region/env 用以标示其所在的集群和发布的环境，group-config 用以标示其使用的分组配置版本，name 用以标识该容器的名称，lb-status 用以标识其在负载均衡中的状态。
在 Kubernetes 中创建 pod 时，我们通常会指定 requests 和 limits，以对资源加以限制。其中 requests 的设置主要会影响 kube-scheduler 的资源调度，而 limits 的值则会影响 pod 所属物理机上的 cgroup 的设置，对 pod 的资源使用做实际的限制。那么 limits 相对来说代表了一个容器可以使用的资源上限，而 requests 代表了容器需要的最小资源。
在用户申请时，用户其实对其容器的资源需求并不能准确把握，因此用户很难一次就设置一个较好的规格。但是用户对其容器需求的资源上限，可以通过压测较好的获得。
我们提供了规格配置的功能，用以供用户进行选择。用户可以通过规格配置的设置，来设置容器的资源上限，也就是 limit 的值。而 request 的值，则会根据容器运行的情况，由系统自动做出调整。
开源项目的一大特点是迭代较快。半年甚至几个月就发布新的一个大的版本。如果跟随社区进行版本的升级，不仅要耗费大量的人力物力用于迁移，而且版本之间可能并不兼容，也容易对现有的容器产生影响。Kubernetes 版本不断进行，这其中会有老的 bug 被修复，也可能会有新的 bug 被引入。这些对于社区都是很正常的。但是对于生产环境来说，又是存在着较大的风险。
根据我们使用 OpenStack 的经验，一种较好的方式是选定一个较为稳定的版本，在其上进行充分的测试，而后基于此版本进行定制研发。大版本的升级需要更加充分的测试，特别是兼容性的测试。我们最初使用的是 1.3 版本，后来升级到目前的 1.6 版本，并将其作为主力版本。已有的集群也都陆续升级到了该版本上。同时，对于社区也需保持一定的关注，对于该版本上可能存在的 bug 和之后有较好的 feature，也陆续合入到定制的版本中。
