k8s基本概念

1）Master模块简介：

    Master是Cluster的大脑，它的主要职责是调度，即决定将应用放在哪里运行。Master运行Linux操作系统，可以是物理机或者虚拟机。为了实现高可用，可以运行多个Master，下面是Master的主要模块。

API Server：

    API Server 提供 HTTP/HTTPS RESTful API，即 Kubernetes API。API Server 是 Kubernetes Cluster 的前端接口，各种客户端工具（CLI 或 UI）以及 Kubernetes 其他组件可以通过它管理 Cluster 的各种资源。

Scheduler：

    scheduler的职责很明确，就是负责调度pod到合适的Node上。如果把scheduler看成一个黑匣子，那么它的输入是pod和由多个Node组成的列表，输出是Pod和一个Node的绑定，即将这个pod部署到这个Node上。Kubernetes目前提供了调度算法，但是同样也保留了接口，用户可以根据自己的需求定义自己的调度算法。

Controller Manager：

    Controller Manager 负责管理 Cluster 各种资源，保证资源处于预期的状态。Controller Manager 由多种 controller 组成，包括 replication controller、endpoints controller、namespace controller、serviceaccounts controller 等。不同的 controller 管理不同的资源。例如 replication controller 管理 Deployment、StatefulSet、DaemonSet 的生命周期，namespace controller 管理 Namespace 资源。比如我们通过APIServer创建一个pod，当这个pod创建成功后，APIServer的任务就算完成了。而后面保证Pod的状态始终和我们预期的一样的重任就由controller manager去保证了。

etcd：

    etcd 负责保存 Kubernetes Cluster 的配置信息和各种资源的状态信息。当数据发生变化时，etcd 会快速地通知 Kubernetes 相关组件。

2）Node节点包含如下模块：

    Node的职责是运行容器应用。Node由Master管理，Node负责监控并汇报容器的状态，并根据Master的要求管理容器的生命周期。

kubelet：

    kubelet是Node agent，当Scheduler确定在某个Node上运行Pod后，会将Pod的具体配置信息（image、volume等）发送给该节点的kubelet，kubelet根据这些信息创建和运行容器，并向 Master 报告运行状态。

kube-proxy：

    service在逻辑上代表了后端的多个Pod，外界通过service访问Pod。service接收到的请求是如何转发到Pod的呢？这就是kube-proxy要完成的工作。每个Node都会运行kube-proxy 服务，它负责将访问service的TCP/UPD数据流转发到后端的容器。如果有多个副本，kube-proxy会实现负载均衡。kube-proxy使用etcd的watch机制，监控集群中service和endpoint对象数据的动态变化，并且维护一个service到endpoint的映射关系，从而保证了后端pod的IP变化不会对访问者造成影响。

3）Pod简介

    Pod是Kubernetes的基本操作单元，也是应用运行的载体。整个Kubernetes系统都是围绕着Pod展开的，比如如何部署运行Pod、如何保证Pod的数量、如何访问Pod等。另外，Pod是一个或多个容器的集合，有些容器天生就是需要紧密联系，一起工作。Pod提供了比容器更高层次的抽象，将它们封装到一个部署单元中。Kubernetes以Pod为最小单位进行调度、扩展、共享资源、管理生命周期。Pod中的所有容器使用同一个网络namespace，即相同的IP地址和Port空间，这些容器可以共享存储，当Kubernetes挂载volume到Pod，本质上是将volume挂载到Pod中的每一个容器。

4）Controller简介

    Kubernetes 提供了多种Controller，包括Deployment Controller、ReplicaSet Controller|Replication Controller、DaemonSet Controller、StatefuleSet Controller、Job Controller 等，我们逐一讨论。

Deployment是最常用的Controller，比如前面在线教程中就是通过创建Deployment来部署应用的。Deployment可以管理Pod的多个副本，并确保Pod按照期望的状态运行，是目前官方推荐的使用方式，因为Deployment拥有更加灵活强大的升级、回滚功能。。

Replication Controller保证在同一时间能够运行指定数量的Pod副本，保证Pod总是可用，一个pod及其副本的集合被一个Replication Controller管理，在用户定义范围内，如果pod增多，则ReplicationController会终止额外的pod，如果减少，RC会创建新的pod，始终保持在定义范围，RC跨多个Node节点监视多个pod，在新的版本中，官方推荐使用Replica Set和Deployment来代替RC。

ReplicaSet实现了Pod的多副本管理。使用Deployment时会自动创建ReplicaSet，也就是说Deployment是通过ReplicaSet来管理Pod的多个副本，我们通常不需要直接使用ReplicaSet。和Replication Controller相比ReplicaSet是支持新的set-based选择器要求的下一代Replication Controller，Replication Controller仅支持equality-based的选择器要求。主要用作Deployment协调pod创建、删除和更新。请注意，除非需要自定义更新编排或根本不需要更新，否则建议使用Deployment而不是直接使用ReplicaSets。

DaemonSet用于每个Node最多只运行一个Pod副本的场景。正如其名称所揭示的，DaemonSet通常用于运行daemon。

StatefuleSet能够保证Pod的每个副本在整个生命周期中名称是不变的。而其他Controller不提供这个功能，当某个Pod发生故障需要删除并重新启动时，Pod的名称会发生变化。同时StatefuleSet会保证副本按照固定的顺序启动、更新或者删除。

Job用于运行结束就删除的应用。而其他Controller中的Pod通常是长期持续运行。

除此之外还有Node Controller管理node，Namespace Controller管理Namespace，Service Controller管理service等等。

5）Service

    Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制，关联多个相同Label的Pod，用户不需要了解后台Pod是如何运行。

   外部系统访问Service的问题，首先需要弄明白Kubernetes的三种IP：Node IP：Node节点的IP地址， 是Kubernetes集群中节点的物理网卡IP地址，所有属于这个网络的服务器之间都能通过这个网络直接通信；Pod IP：Pod的IP地址, 是Docker Engine根据docker0网桥的IP地址段进行分配的，通常是一个虚拟的二层网络；Cluster IP：Service的IP地址，一个虚拟的IP，作用于Kubernetes Service这个对象，并由Kubernetes管理和分配IP地址