本文源自——《Kubernetes权威指南》

1. Kubernetes是什么？

Kubernetes是一个全新的基于容器技术的分布式架构领先方案。

Kubernetes是谷歌严格保密十几年的秘密武器——Borg的一个开源版本。

使用Kubernetes提供的解决方案，我们不仅节省了不少于30%的开发成本，同时可以将精力更加集中于业务本身，而且由于Kubernetes提供了强大的自动化机制，所以系统后期的运维难度和运维成本大幅降低。

由于Kubernetes平台对现有的编程语言、编程框架、中间件没有任何侵入性，因此现有的系统也很容器改造升级并迁移到Kubernetes平台上。

Kubernetes是一个完备的分布式系统支撑平台。Kubernetes具备完备的集群管理能力，包括：

• 多层次的安全防护和准入机制
• 多租户应用支撑能力
• 透明的服务注册和服务发现机制
• 内建智能负载均衡器
• 强大的故障发现和自我修复能力
• 服务滚动升级和在线扩容能力
• 可扩展的资源自动调度机制
• 多粒度的资源配额管理能力

Kubernetes提供了完善的管理工具，这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节。

1.1 Service

在Kubernetes中，Service（服务）是分布式系统架构的核心，一个Service对象拥有如下关键特征：

• 拥有一个唯一指定的名字（比如mysql-server）；
• 拥有一个虚拟IP（ClusterIP、ServiceIP或VIP）和端口号；
• 能够提供某种远程服务能力；
• 被映射到了提供这种服务能力的一组容器应用上。

Kubernetes能够让我们通过Service（虚拟ClusterIP+Service Port）连接到指定的Service上。有了Kubernetes内建的透明负载均衡和故障恢复机制，不管后端有多少服务进程，也不管某个服务进程是否会由于发生故障而重新部署到其他机器，都不会影响到我们对服务的正常调用。
Service一旦创建就不再发送变化。

2. Kubernetes的基本概念和术语

2.1 Master

Master指的是集群控制节点，每个Kubernetes集群里需要有至少一个Master节点来辅助整个集群的管理和控制，基本上Kubernetes的所有控制命令都发给它，它来负责整个集群的管理和控制。
Master节点上运行着以下一组关键进程：

• Kubernetes API Server（kube-apiserver）：提供了HTTP REST接口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程；
• Kubernetes Controller Manager（kube-controller-manager）：Kubernetes里所有资源对象的自动化控制中心，可以理解为资源对象的“大总管”。
• Kubernetes Scheduler（kube-scheduler）：负责资源调度（Pod调度）的进程，相当于公交公司的 “调度室”。

另外，在Master节点上还需要启动一个etcd服务，因为Kubernetes里所有资源对象的数据全部保存在etcd中。

2.2 Node

除了Master外，Kubernetes集群中的其他机器被称为Node节点。
Node节点是Kubernetes集群中的工作负载节点，每个Node都会被Master分配一些工作负载（Docker容器），当某个Node宕机时，其上的工作负载会被Master自动转移到其他节点上 去。

每个Node节点上都运行着下面一组关键进程：

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

2.3 Pod

Pod是Kubernetes的最重要也是最基本的概念。
在Kubernetes里，一个Pod里的容器与另外主机上的Pod容器能够直接通信。
Pod有两种类型：普通Pod和静态Pod（Static Pod）。

2.4 Event

Event是一个事件的记录，记录了事件的最早产生时间、最后重现时间、重复次数、发起者、类型，以及导致此事件的原因等众多信息。
Event通常会关联到某个具体的资源对象上，是排查故障的重要参考信息。

2.5 Label（标签）

一个Label是一个key=value的键值对，其中key与value由用户自己指定。

Label可以附加到各种资源对象上，例如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上。

2.6 Label Selector

Label Selector可以被类比为SQL语句中的where查询条件。

Label Selector在Kubernetes中的重要使用场景有以下几处：

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

2.7 Replication Controller

Replication Controller 简称 RC。
RC定义了一个期望的场景，即声明某种Pod的副本数量在任意时刻都符合某个预期值，所以RC的定义包括如下几个部分：

• Pod期待的副本数（replicas）；
• 用于筛选目标Pod的Label Selector；
• 当Pod的副本数量小于预期数量时，用于创建新Pod的Pod目标（template）。

下面是一个完整的RC定义示例：

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-controller
spec:
  replicas: 2
  # selector identifies the set of Pods that this
  # replication controller is responsible for managing
  selector:
    app: nginx
  # podTemplate defines the 'cookie cutter' used for creating
  # new pods when necessary
  template:
    metadata:
      labels:
        # Important: these labels need to match the selector above
        # The api server enforces this constraint.
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

2.8 Replica Set

Replica Set是下一代的RC。
它与RC当前存在的唯一区别是：Replica Set支持基于集合的Label Selector，而RC只支持基于等式的Label Selector，这使得Replica Set的功能更强

2.9 Deployment

Deployment在内部使用Replica Set来实现目的，其相对于RC的一个最大升级是我们可以随时知道当前Pod“部署”的进度。

Deployment的典型应用场景有以下几个：

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

2.10 Horizontal Pod Autoscaler

Horizontal Pod Autoscaler（Pod横向自动扩容，简称HPA)。
HPA通过追踪分析RC控制的所有目标Pod负载变化情况，来确定是否需要针对性地调整目标Pod的副本数。

当前HPA可以有以下两种方式作为Pod负载的度量指标：

• CPUUtilizationPercentage
• 应用程序自定义的度量指标，比如服务QPS或TPS

CPUUtilizationPercentage计算过程中使用到的Pod的CPU使用量通常是1min内的平均值，目前通过查询Heapster扩展组件来得到这个值，所以需要安装部署Heapster。

HPA

下面是HPA定义的一个具体示例：

apiVersion: autoscaling/v2alpha1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1beta1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 50
status:
  observedGeneration: 1
  lastScaleTime: <some-time>
  currentReplicas: 1
  desiredReplicas: 1
  currentMetrics:
  - type: Resource
    resource:
      name: cpu
      currentAverageUtilization: 0
      currentAverageValue: 0

2.11 StatefulSet

StatefulSet是面向有状态服务的，例如MySQL集群、MongoDB集群等，这些应用集群由一下一些共同点：

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

StatefulSet有如下一些特性：

• StatefulSet中的每个Pod都有稳定、唯一的网络标志，可以用来发现机器内的其他成员。假设StatefulSet的名字叫kafka，那么第1个Pod叫做kafka-0，第2个叫kafka-1，以此类推；
• StatefulSet控制的Pod副本的启停顺序是受控的，操作第n个Pod时，前n-1个Pod已经是运行且准备好的状态；
• StatefulSet里的Pod采用稳定的持久化存储卷，通过PV/PVC来实现，删除Pod时默认不会删除与StatefulSet相关的存储卷（为了保证数据的安全）。