[kubernetes]第二节：kubernetes核心概念

    1.Pod
     Kuberbetes的基本调度单元是Pod，一个Pod包含一个或者多个容器，这样可保证一在同一个Pod内的容器都运行在同一个宿主机上（可理解为openstack每个计算节点为一个nova可用域）,并且可共享资源，这些容器适用相同的网络命名空间、IP地址和端口。 Kubernetes中的每个Pod都被分配一个唯一的IP地址，这样就可以允许应用程序使用端口而不会有冲突的风险。另外,同一个Pod的容器还可共享一块存储卷空间,可以定义一个卷,如本地磁盘目录或网络磁盘。在 Kubernetes中创建、调度和管理的最小单位是Pod,而不是 Docker容器。用户可以通过 Kubernetes api手动管理Pod,也可以委托给控制器来管理Pod。
     2.Replication Controller
    Replication Controller用于管理、控制Pod的副本数,用于解决Pod的扩容、缩容问题。通常,分布式应用为了性能或高可用性的考虑,需要复制多份资源,并且根据负载情况实现动态伸缩。通过 Replication Controller,我们可以指定一个应用需要几份副本,Kubernetes将为每份副本创建一个Pod,并且保证实际运行Pod数量总是与该副本数量相等。如果少于指定数量的Pod副本, Replication Controller会重新启动新的Pod副本,反之会“杀死”多余的副本以保证数量不变。
     3. Service
     Service是真实应用服务的抽象,定义了Pod的逻辑集合和访问这个集合的策略。Service是一组协同工作的Pod,就像多层架构应用中的一层,是Pod的路由代理抽象,用于解决Pod之间的服务发现问题。因为Pod的运行状态可动态变化(比如,Pod迁移到其他
机器或者在缩容过程中被终止等),所以访问端不能以固定IP的方式去访问该Pod提供的服务。 Service的引入旨在保证Pod的动态变化对访问端透明,访问端只需要知道 Service的地址,由 Service来提供代理。构成服务的Pod组通过 Label选择器来定义。 Kubernetes通过给服务分配静态I地址和域名来提供服务发现机制,并且以轮询调度的方式将流量负载均衡到能与选择器匹配的Pod的IP地址的网络连接上(即使是故障导致Pod从一台机器移动到另一台机器)。默认情况下,一个服务会暴露在集群中(例如,多个后端Pod可能被分组成一个服务,前端Pod的请求在它们之间负载均衡);但是,一个服务也可以暴露在集群外部(例如,从客户端访问前端Pod
     4. Label Z Label Selector
Kubernetes将称为“ Label”的键一值对附加到系统中的任何API对象上,如Pod、 Service、 Replication Controller等。实际上, Kubernetes中的任意API对象都可以通过Label进行标识。每个API对象可以有多个 Label,但每个 Label的Key只能是唯一值。相应地, Lable selector则是针对匹配对象的标签来进行的查询。 Label和 Label selector是Kubernetes中的主要分组机制,用于确定操作适用的组件。例如,如果应用程序的Pod具有系统的标签tier(例如,“ front-end"、“back-end”)和一个 release track(例如,“ canary production”),那么对所有back-end和 canary节点的操作可以使用如下所示的 Label Selector tier=back-end AND release track=canary 。
     5. Node
Node也称为 Worker或 Minion节点,是主从分布式集群架构的计算单元,是分配给Pod并运行Pod的宿主机。 Kubernetes集群中的每个计算节点都必须运行 Docker引擎以及面提到的组件,以便与这些容器的网络配置进行通信。每个Node节点主要由三个模块组成: kubelet、kube- proxy、 runtime
     6. Master
Master是 Kubernetes分布式集群的管理控制中枢,所有任务分配都来自于此。 Master节点主要由四个模块组成: API Server、 scheduler、 controller manager、etcd