kubernetes 核心术语

kubernetes 是一个开放的开发平台。对现有的编程语言、编程框架、中间件没有任何的侵入性。它有完备的集群管理能力，包括多层次的安全防护和准入控制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建的智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。kubernetes还提供了完善的管理工具，包括开发、测试、部署、监控等流程。因此kubernetes是一个基于容器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台。

image.png

Master

Master 指的是集群的控制节点，在每个kubernetes集群中都需要一个Mater来负责整个集群的管理和控制。几乎所有的控制命令都会给到master，它负责具体的执行过程。matster通常会占用一个独立的服务器（高可用部署建议用3台服务器）。如果master宕机，那么kubernetes对集群应用的管理将会失效。

master上运行以下关键进程：

kubernetes API Server (lube-apiserver)：提供了HTTP Rest接口的关键服务进程，是kubernetes里所有资源的增删改查等操作的唯一入口，也是集群控制的入口进程。
kubernetes Controller Manager(kube-controller-manager)：所有资源对象的自动化控制中心。
kubernetes Scheduler (kube-scheduler)：负责资源调度（pod调度）的进程。

另外，在Master上还需要部署etcd服务，因为kubernetes里的所有资源对象都被保存在etcd中。

Node

kubernetes中的其它机器被称为Node，是kubernetes中的工作负载节点，每个Node都会被master分配一些工作负载（Docker容器），当某个Node宕机时，其上的工作负载会被Master自动转移到其它节点上。

每个Node上都运行着以下关键进程。

kubelet ：负责pod对应的容器的创建、启停等任务，同时与Master密切协作实现基本的集群管理功能、
kube-proxy ：实现service的通信和负载均衡机制的重要组件。
Docker Engine (docker)：Docker 引擎，负责本机的容器的创建和管理工作。

Pod

image.png

Pod是kubernetes最小部署单元，一个Pod包含多个容器。每个Pod都有一个被称为根容器的Pause容器。Pause容器对应的镜像属于kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或多个密切相关的用户业务容器。

一个Pod中有多个容器的设计可以有以下优势：

整体的控制一组容器，让他们有相同的生命周期。
Pod 中的容器共享挂载或网络命名空间

Label

Label是一个可以让用户自定义的key/value形式的键值对，Label可以被附加到如Pod、Service、RC等各种kubernetes资源对象上。Label通常在定义资源时指定,也可以在对象创建后动态的添加或删除。

"metadata": {
  "labels": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

Label Selector可以查询或筛选具有某些标签的kubernetes资源对象，其在kubernetes重要使用场景如下：

kube-controller 进程通过在资源对象RC上定义的Label Selector来筛选要监控的Pod副本数量，使Pod副本数量始终符合预期设定的全自动控制流程。
kube-proxy 进程通过Service的Label Selector来选择对应的Pod，自动建立每个Service到Pod的请求转发路由表，从而实现Service的智能负载均衡机制。
通过某些Node定义特定的Label，并且在Pod定义文件中使用NodeSelector这种标签调度策略，kube-schduler进程可以实现Pod定向调度的特性。

Replication Controller

简称RC，它定义了某种Pod的副本数量在任意时刻都符合某个预期的期望，RC包括如下几个部分：

Pod期待的副本数量
用于筛选目标Pod的LabelSelector
当Pod的副本数量小于预期数量时，用于创建新Pod的Pod模板。

Deployment

Deployment内部使用Replia Set来解决Pod的编排问题，在未来这个功能正在一点点的替换RC。其典型使用场景有以下几个：

创建一个Deployment对象来生成对应的Replica Set并完成Pod副本的创建。
检查Deployment来看部署动作是否完成（Pod副本数量是否达到预期的值）。
更新Deployment以创建新Pod（比如镜像更新）。
如果当前的Deployment不稳定，则回滚到一个早先的Deployment版本。
暂停Deployment以便于一次性修改多个PodTemplateSpec的配置项，之后再恢复Deployment，进行新的发布。
扩展Deployment以应对高负载。
查看Deployment状态，以此作为发布是否成功的指标。
清理不再需要的旧版本ReplicaSets。

image.png

Service

Service 是一个抽象的概念，，它定义了一个服务的的访问入口地址，前端应用通过这个入口地址来访问其背后由Pod组成的集群实例，Service与其后端的Pod副本之间则是通过LabelSelector之间无缝对接的。

image.png

kubernetes 服务发现

通过提供特定的api接口来做服务发现对导致平台的侵入性较强，也增加了开发、测试的难度。所以kubernetes使用DNS作为服务发现，直接使用服务名作为域名。

外部系统访问Service

   internet
        |
   [ Ingress ]
   --|-----|--
   [ Services ]

Service的Cluster Ip特点如下：

Cluster IP 仅仅作用域Service这个对象，并由kubernetes管理和分配ip地址（来源与Cluster IP地址池）。
无法被ping，因为没有一个“实体的网络对象”来响应。
只能结合Service Port组成一个具体的通信端口，单独的Cluster IP不具备TCP/IP通信的基础，并且它们属于kubernetes集群这样一个私有空间，集群外部的节点如果要访问这个通信端口，需要做一些额外的工作。
在kubernetes集群内，Node IP网、Pod IP网与Cluster IP网之间的通信，采用的是kubernetes自己设计的一种编程式的特殊路由规则，与我们熟知的ip路由有很大的不同。

StatefulSet

StatefulSet是kubernetes专门为有状态的应用集群定制的一种集群模式，如kafka集群、etcd集群这些集群有以下4个共同点：

每个节点都有固定的身份ID，集群成员可以通过这个ID相互发现并通信。
集群规模比较固定，不会随意变动。
每个节点都是有状态的，通常会持久化数据到永久存储中。
如果磁盘损坏或某个节点无法正常运行，则集群可能受损。

RC和Deployment无法满足上述四点，所以StatefulSet作为补充提供了以下特性：

每个Pod都很稳定，拥有唯一的网络标识。
Pod副本的启停顺序是受控的。
Pod采用稳定的持久化存储卷，通过PV或PVC来实现。
支持Headless Service，不使用Cluster IP，解析DNS域名时返回全部Pod的Endpoint列表。

从上面的特性可以看出，Cluster IP属于kubernetes集群内部私有地址，无法在集群外部直接使用这个地址。

Namespace

namespace是kubernetes实现多租户隔离的重要概念，通过namespace可将集群内部的资源分配到不同的命名空间中，形成逻辑上不同的分组，便于不同的分组共享使用集群资源时还能被分别管理。默认情况下用户创建的RC、Pod、Service都被分配到default命名空间中。

ConfigMap

kubernetes提供的配置中心，原理是通过Volume的方式挂载位于etcd的配置数据。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      Name: game-demo
    data:
      # 类属性键；每一个键都映射到一个简单的值
      player_initial_lives: 3
      ui_properties_file_name: "user-interface.properties"
      #
      # 类文件键
      game.properties: |
        enemy.types=aliens,monsters
        player.maximum-lives=5
        user-interface.properties: |
        color.good=purple
        color.bad=yellow
        allow.textmode=true

Volume

Volume存储卷是Pod中能够被多个容器共享的的目录，其生命周期只与Pod有关，而与容器无关。kubernetes支持多种类型的volume，举例如下：

emptyDir

emptyDir Volume在Pod分配到Node时创建，它无需对应宿主机上的任何文件，当Pod从Node上移除时自动删除。emptyDir应用场景如下：

临时空间。
多容器共享目录。

hostPath

挂载宿主机是哪个的文件或目录到Pod，主要使用场景如下：

保存日志文件。
访问docker引擎内部数据结构。

注意hostPath上无法使用资源配额管理。

云存储

如 GCE和AWS。

其它存储

支持nfs等网络或开源存储。

Persistent Volume

Volume存储被定义在Pod上，属于计算资源的一部分。而PV是集群某个网络存储对应的一块存储。其与Volume有以下区别：

PV只能是网络存储，不属于任何Node，但是可以在每个Node上访问。
PV并不定义在Pod上。

Horizontal Pod Autoscaler

水平扩容的设计目标是使kubernetes中的应用有根据当前负载的变化，自动的触发水平扩容或缩容。HPA通过追踪RC控制的所有的Pod负载变化情况，来确定是否有必要针对性的调整目标副本数量。当前HPA有以下两种方式作为Pod负载度量指标：

CPUUtilizationPercentage ：Pod当前的cpu使用率除以Pod Request的平均值。
应用程序自定义度量指标，例如TPS、QPS。

Job

Job 资源对象控制一组Pod容器，用于定义并启动一个批处理任务。批处理任务通常串行或并行的启动多个计算进程去处理一批工作项，在处理完成后，整个批处理任务结束。Job与RC等控制器有以下差别：

Job控制的副本是短暂运行的，可以将其视为一组docker容器，其中每个docker容器都仅仅运行一次。Job生成的Pod副本的RestartPoliy被设置为Nerver，意思是不会自动重启。kubernetes还支持cronJob，用于支持某些批处理任务需要反复执行的问题。
Job所控制的Pod副本的工作模式能够多实例并行计算。