name:mysql-server
Master
业务2（后端）container
是Kubernetes最基本的部署调度单元，可以包含container，逻辑上表示某种应用的一个实例。比如一个web站点应用由前端、后端及数据库构建而成，这三个组件将运行在各自的容器中，那么我们可以创建包含三个container的pod。
RC(Replication controller)
Pod
...metadata: name: mysqlspec: replicas: 1 selector: app: mysql......
RC
ip:port
kubelet:负责管控docker容器，如启动/停止、监控运行状态等。它会定期从etcd获取分配到本机的pod，并根据pod信息启动或停止相应的容器。同时，它也会接收apiserver的HTTP请求，汇报pod的运行状态。
Pause容器（业务容器共享pause容器的网络栈和Volumn挂载卷）
Lable:passport
service
gloud-provider-passport容器
Lable:mysql
业务1（前端）container
mysql容器
kube-proxy：负责为pod提供代理。它会定期从etcd获取所有的service，并根据service信息创建代理。当某个客户pod要访问其他pod时，访问请求会经过本机proxy做转发。
1.目标pod的定义
3.kube-controller-manager：负责执行各种控制器，目前有两类： endpoint-controller：定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。 replication-controller：定期关联replicationController和pod，保证replicationController定义的复制数量与实际运行pod的数量总是一致的。
3.目标pod的标签(Label)
Node（slave）
业务3（数据库）container
label selector:passport
node...
是pod的复制抽象，用于解决pod的扩容缩容问题。通常，分布式应用为了性能或高可用性的考虑，需要复制多份资源，并且根据负载情况动态伸缩。通过replicationController，我们可以指定一个应用需要几份复制，Kubernetes将为每份复制创建一个pod，并且保证实际运行pod数量总是与该复制数量相等(例如，当前某个pod宕机时，自动创建新的pod来替换)。
是pod的路由代理抽象，用于解决pod之间的服务发现问题。因为pod的运行状态可动态变化(比如切换机器了、缩容过程中被终止了等)，所以访问端不能以写死IP的方式去访问该pod提供的服务。service的引入旨在保证pod的动态变化对访问端透明，访问端只需要知道service的地址，由service来提供代理。
2.kebu-scheduler：负责集群的资源调度，为新建的pod分配机器。这部分工作分出来变成一个组件，意味着可以很方便地替换成其他的调度器。
name:gloud-provider-authorize
1.kuber-apiserver：作为kubernetes系统的入口，封装了核心对象的增删改查操作，以RESTFul接口方式提供给外部客户和内部组件调用。它维护的REST对象将持久化到etcd（一个分布式强一致性的key/value存储）。
label selector:mysql
2.目标pod需要定义副本数量
apiVersion: v1kind: ReplicationController #副本控制器RCmetadata: name: mysql #RC名称，全局唯一spec: replicas: 1 #pod副本期待数量 selector: app: mysql #目标pod标签 template: #根据此模板创建pod实例 metadata: labels: app: mysql #pod标签，对应rc selector spec: containers: #pod容器定义部分 - name: mysql #容器名称 image: mysql #容器对应docker image ports: - containerPort: 3306 #容器应用监听端口号 env: #注入容器内的环境变量 -name: MYSQL_ROOT_PASSWORD value: \"123456\"
name:gloud-provider-passport
