Kubernetes入门（七）

01.Replication Controller

Replication Controller（RC）是Kubernetes的另一个核心概念，应用托管在Kubernetes上之后，Kubernetes需要保证应用能够持续运行，这就是RC的工作内容，它会确保任何时间Kubernetes中都有指定数量的Pod在运行。同时RC还提供了一些高级特性，比如滚动升级，升级回滚等。

RC与Pod的关联—Label

RC与Pod的关联是通过Label来实现的。Label机制是Kubernetes中的一个重要设计，通过Label进行对象的弱关联，可以灵活地进行分类和选择。对于Pod，需要设置其自身的Label来进行标识，Label是一系列的Key/Value对，在Podàmetadataàlabels中进行设置。Label的定义是任意的且不具有唯一性，所以为了更准确的标识一个Pod，应该为Pod设置多个维度的label。

弹性伸缩

弹性伸缩是指适应负载变化，以弹性可伸缩的方式提供资源。反映到Kubernetes中，指的是可根据负载的高低来动态调整Pod的副本数量。

滚动升级

滚动升级时一种平滑过渡的升级方式，通过逐步替换的策略，保证整体系统的稳定。在初始升级的时候就可以及时发现、调整问题，以保证问题影响度不会扩大。

新一代副本控制器Replica Set

Replica Set可以认为时“升级版“的Replication Controller。当V1版本的Kubernetes被弃用之后，Replication Controller就完成了它的历史使命，而由Replica Set来接管它的工作。虽然Replica Set可以单独使用，但是它目前多被Deployment用于进行Pod创建、更新与删除。

02.Job

从程序的运行状态来分，可以将Pod分为两类：长时运行的服务和一次性任务。RC创建的Pod都是长时运行的服务，而Job创建的Pod都是一次性任务。

03.Service

Kubernetes的Service是一种抽象概念，它定义了一个Pod逻辑集合以及访问它们的策略。Service的目标是提供一种桥梁，它会为访问者提供一个固定的访问地址，用于在访问时重定向到相应的后端。Service同样时通过Label来关联Pod的，Service作为Pod的访问入口，起到代理服务器的作用，而对于访问者来说，通过Service进行访问，无需直接感知Pod。

Service代理外部服务

Service不仅可以代理Pod，还可以代理任意其他后端，比如运行在Kubernetes外部的MySQL，Oracle等。

Service内部负载均衡

当Service的endpoint包含多个IP时，即服务代理存在多个后端，将进行请求的负载均衡，默认的负载均衡策略时轮询或者随机（由kube-proxy的模式决定）。通过在Service上设置ServiceàspecàsessionAffinity = ClientIP来实现基于源IP地址的会话保持。

发布Service

Service的虚拟IP是由Kubernetes虚拟出来的内部网络，外部是无法寻址到的。但是有些服务又需要被外部访问，比如web服务。这时就需要加一层网络转发，即外网到内网的转发。Kubernetes提供了三种方式：NodePort，LoadBalancer，Ingress。

NodePort，其原理是，Kubernetes会在每个Node上暴露一个端口：nodePort，外部网络可以通过[NodeIP]:[NodePort]访问到后端的service。

LoadBalancer，在NodePort的基础上，Kubernetes可以请求底层云平台创建一个负载均衡器，将每个Node作为后端，进行服务分发。该模式需要底层云平台支持。

Ingress，是一种HTTP方式的路由转发机制，由Ingress Controller和HTTP代理服务器组合而成。Ingress Controller实时监控Kubernetes API，实时更新HTTP代理服务器的转发规则。HTTP代理服务器有GCE Load-Balancer，Nginx等开源方案。

Service自发性机制

Kubernetes中有一个很重要的服务自发现特性。一旦一个service被创建，该service的serviceIP和service port等信息都可以被注入到Pod中供它们使用。两种服务发现机制：环境变量和DNS

环境变量方式

Kubernetes创建Pod时会自动添加所有可用的service环境变量到该Pod中，如有需要，这些环境变量也会被注入到Pod内的容器中。环境变量的注入只发生在Pod创建时，且不会被自动更新，所以任何要访问service的Pod都需要在service已存在后创建，否则与service相关的环境变量就无法注入到Pod的容器中，这样先创建的容器就无法发现后创建的service。

DNS方式

Kubernetes集群支持一种可选的组件-DNS服务器。这个DNS服务器使用Kubernetes的watch API，不间断的监测新的service的创建并为每一个service新建一个DNS记录。如果DNS服务在整个集群范围内可用，那么所有的Pod都能够自动解析service域名。

4. Deployment

Kubernetes提供了一种更加简单的更新RC和Pod的机制，叫做Deployment。通过在Deployment中描述所期望的集群状态，Deployment Controller会将现在的集群状态在一个可控的速度下逐步更新成所期望的集群状态。Deployment的主要职责同样是为了保证Pod的数量和健康，90%的功能与Replication Controller一样，可以看成是新一代的Replication Controller。但是他又具有一些新的特性：

Replication Controller全部功能：Deployment继承了RC的全部功能。

事件和状态查看：可以查看Deployment的升级详细进度和状态。

回滚：当升级Pod镜像或者相关参数时发现问题，可以使用回滚操作回滚到上一个稳定的版本或指定的版本。

版本记录：每次对Deployment的操作都能保存下来，给予后续可能的回滚使用。

暂停和启动：对于每一次升级，都能够随时暂停和启动。

多种升级方案：Recreate—删除所有已存在的Pod，重新创建新的；RollingUpdate—滚动升级，逐步替换的策略，支持更多的附加参数。

4. Volum

在Docker的设计实现中，容器中的数据是临时的，当容器被销毁时，其中的数据将会消失，如果需要持久化数据，需要使用Docker数据卷挂载宿主机上的文件或者目录到容器中。在Kubernetes中，当Pod重建时，数据也是会丢失的，Kubernetes也是通过数据卷挂载来提供Pod的持久化的。Kubernetes数据卷是对Docker数据卷的扩展，Kubernetes数据卷是Pod级别的，可以实现Pod中容器的文件共享。