一般情况下，开发环境中使用的K8S都是多个项目共同使用的，在namespace层面就可以进行隔离各个项目间对环境和资源的依赖了，而生产环境则相对纯粹，各个项目所运行的环境的欧式相对独立的，资源独占的。
这时，对于新接入的项目，在开发环境不存在初期试错的代价，那么生产环境部署多少会有风险的。
资源通常K8S使用的3个物理机就可以搞起来了，当然一个也行，生产环境规划对于ingress独占2台，这个作为服务入口太重要了，多给点资源不为过，master使用3台保证整体服务高可用，可以适当给小点规格，master的运行过程中对资源消耗不大，且对机器资源占用相对稳定（据一个资深开发所说）。
网络K8S的底层网络通常是运维接触的，相对集群而言，集群内部的容器组互相之间使用SVC的node ip + port或者clusterIP够用，SVC的name如果出现不可用的情况，需要看看K8S内部的DNS。
“ImgPullErr”需要看看有没有拉取镜像的凭证，如果生产环境和开发环境网络打通，可以考虑直接使用QA验证过的镜像，在生产的环境中增加一个拉取密钥就可以。
Endpoints和SVC，组合一下，可以把集群外部的服务代理到集群内部，通过SVC的name使用，一般情况，同一局域网内部，容器组内的容器可以直接访问集群外的主机服务，但是如果需要K8S的Ingress代理出去，可以这么操作。
——这点踩了一个坑：endpoints和SVC单独创建时，查看endpoints时，出现过，endpoints对应实际服务ip和端口缺失的情况，后经运维排查，也找不到原因，后来经尝试，使用一个yaml同时创建endpoints和SVC时，不出现该问题！
