对于微服务或分布式系统来说，业务越复杂，系统越庞大，部署维护越麻烦，需要的时间和人力成本大幅提高，同时人工管理配置错综复杂，尤其是对于调整升级和收缩扩容，部署运维简直就是灾难，所以容器管理引擎和平台刻不容缓。
什么是k8s（kubernetes）
Kubernetes是Google开源的容器集群管理系统，使用Golang开发，其提供应用部署、维护、扩展机制等功能，利用Kubernetes能方便地管理跨机器运行容器化的应用。使用Kubernetes可以：
- 自动化容器的部署和复制
- 随时扩展或收缩容器规模
- 将容器组织成组，并且提供容器间的负载均衡
- 很容易地升级应用程序容器的新版本
- 提供容器弹性，如果容器失效就替换它，等等…
- master k8s主服务，核心服务；
- node 相当于一台物理或虚机，每一个node都需要各自的kubelet做容器管理，kube-proxy做网络代理转发；
- kubelet kubelet运行在每个节点上，作为整个系统的agent，监视着分配到该节点的Pods任务，负责挂载Pods所依赖的卷组，下载Pods的秘钥，运行Pods中的容器（通常是docker），周期获取所有容器的状态，通过导出Pod和节点的状态反馈给REST系统；
- kube-proxy 运行在每个节点上，负责整个网络规则的连接与转发；
- kuberctl 管理命令客户端；
- web ui web管理端；
- scheduler 扫描和任务调度；
- api server 核心api接口；
- etcd 持久化存储；
- replication controller 容器复制控制，控制容器数量，自动增加和销毁，实现收缩和扩容；RC通过label关联对应的Pods，通过修改Pods的label可以删除对应的Pods在需要对Pods中的容器进行更新时，RC采用一个一个替换原则来更新整个Pods中的Pod；
- pod 一个node可包含多个pod，pod包含多个容器，pod在同以host上，所以网络ip端口均可以通过localhost通讯，还可以共享存储卷空间；pod是ks中调度和管理的最小单位；
- pods RC通过定义的Pod模板被创建，创建后对象叫做Pods（也可以理解为RC）;
- container 容器，比如docker容器；
- image 一指打包构建后的可在容器中运行的image镜像；
- lable pod的标签，可以包含多个不为维度的定义；
- service 通过label指向pods提供服务，service至创建起即拥有固定的地址，作为外部服务提供者；
spring cloud eureka的注册中心和ribbon负载均衡如何与k8s结合？
我们知道，分布式系统中避免单节点的存在，借助于注册中心和负载均衡策略，我们可有有效避免单节点的存在，有效保障服务的高可用。比如在spring cloud中，利用eureka的相互注册、微服务的注册机制和ribbon，再结合jenkins即可做到自动化高可用部署。
在k8s中，请求到service的时候，我们看下service做了什么
Service是对一组提供相同功能的Pods的抽象，并为它们提供一个统一的入口。借助Service，应用可以方便的实现服务发现与负载均衡，并实现应用的零宕机升级。Service通过标签来选取服务后端，一般配合Replication Controller或者Deployment来保证后端容器的正常运行。
Service有三种类型：
- ClusterIP：默认类型，自动分配一个仅cluster内部可以访问的虚拟IP
- NodePort：在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过
:NodePort来访问改服务 - LoadBalancer：在NodePort的基础上，借助cloud provider创建一个外部的负载均衡器，并将请求转发到
:NodePort
我们可以依靠冗余策略来消除单点以保证ETCD和Master无论何时都始终可用，那么鉴于kubernetes的pod机制，如果Kubernetes自身高可用的话，保证服务rc的pod数量大于1，是否就达到了高可用的目的？
关于负载均衡
spring cloud系统中，可以设置网管、ribbon来实现负载均衡策略，也可以通过k8s的service负载均衡策略，最外层我们也可以借助nginx。使用何种的升级策略，关键在于我们业务的需求，
镜像到服务发布流程
- 将jar服务打包镜像；
- 通过镜像创建运行容器；
3 创建pod模板，将容器加入到模板； - 执行rc，创建pods
- 根据pods创建服务,制定端口映射；
- 外部nginx转发，完成。