开始读书时间 2020.07.01

第1章　Kubernetes入门

1.1 Kubernetes是什么

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

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

3.Borg是谷歌的一个久负盛名的内部使用的大规模集群管理系统，它基于容器技术，目的是实现资源管理的自动化，以及跨多个数据中心的资源利用率的最大化。

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

5.是一个开放的开发平台。它不局限于任何一种语言，没有限定任何编程接口，不论是用Java、Go、C++还是用Python编写的服务，都可以被映射为Kubernetes的Service（服务），并通过标准的TCP通信协议进行交互。此外，Kubernetes平台对现有的编程语言、编程框架、中间件没有任何侵入性，因此现有的系统也很容易改造升级并迁移到Kubernetes平台上。

6.是一个完备的分布式系统支撑平台。Kubernetes具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建的智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。

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

8.总结：Kubernetes是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式的完备的分布式系统开发和支撑平台。

Kubernetes基础知识

  • kubernetes集群是基于Socket通信方式通过Service服务对外提供服务，而对内真正运行服务的容器叫做pod。

  • Service是分布式集群架构的核心，一个Service对象拥有如下关键特征。

    • 拥有唯一指定的名称（比如mysql-server）。
    • 能够提供某种远程服务能力。
    • 被映射到提供这种服务能力的一组容器应用上。

  • Pod是kubernetes中运行的最小单元，是真正运行的服务，但pod是变动的（ip变，运行的节点变，数量变）

  • Service一旦创建就不会变动，是以 虚拟Cluster IP +ServicePort 形式对外提供服务

  • Service 和Pod 是通过Label关联的

  • 在每个Pod中都运行着一个特殊的被称为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷

组件架构上分为Master 和Node

  • Master：实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且都是自动完成的

    • kube-apiserver
    • kube-controller-manager
    • kubescheduler

  • Node：负责Pod的创建、启动、监控、重启、销毁，以及实现软件模式的负载均衡器。

    • kube-proxy
    • kubelet

在Kubernetes集群中，只需为需要扩容的Service关联的Pod创建一个RC（ReplicationController）

在一个RC定义文件中包括以下3个关键信息：

  • 目标Pod的定义
  • 目标Pod需要运行的副本数量（Replicas）
  • 要监控的目标Pod的标签

1.2 为什么要用Kubernetes

1.节省技术成本、人员成本

2.融合微服务架构，提高系统的稳定性和快速迭代能力，开发者也可以自由选择开发技术。

3.Kubernetes的架构方案中完全屏蔽了底层网络的细节，无需考虑底层硬件拓扑问题，业务无需改变运行期的配置文件，无缝上云。

4.服务弹性扩容机制可以轻松应对服务高峰期，节省成本。

5.超强的横向扩容能力可以让我们的竞争力大大提升。

1.3 从一个简单的例子开始

1.3.1 环境准备

1.3.2 启动MySQL服务

1.3.3 启动Tomcat应用

1.3.4 通过浏览器访问网页

1.4 Kubernetes的基本概念和术语

可以采用YAML或JSON格式声明（定义或创建）一个Kubernetes资源对象，每个资源对象都有自己的特定语法格式（可以理解为数据库中一个特定的表），但随着Kubernetes版本的持续升级，一些资源对象会不断引入新的属性。

1.4.1 Master

Kubernetes里的Master指的是集群控制节点，负责整个集群的管理和控制，基本上Kubernetes的所有控制命令都发给它，Master通常会占据一个独立的服务器（高可用部署建议用3台服务器），主要原因是它太重要了，是整个集群的“首脑”，如果它宕机或者不可用，那么对集群内容器应用的管理都将失效。

在Master上运行着以下关键进程：

  • Kubernetes API Server（kube-apiserver）：

    提供了HTTPRest接口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作的唯一入口，也是集群控制的入口进程。

  • Kubernetes ControllerManager（kube-controller-manager）：

    Kubernetes里所有资源对象的自动化控制中心，可以将其理解为资源对象的“大总管”。

  • KubernetesScheduler（kube-scheduler）：

    负责资源调度（Pod调度）的进程，相当于公交公司的“调度室”。

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

1.4.2 Node

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

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

  • kubelet

    负责Pod对应的容器的创建、启停等任务，同时与Master密切协作，实现集群管理的基本功能。

  • kube-proxy

    实现KubernetesService的通信与负载均衡机制的重要组件。

  • DockerEngine（docker）

    Docker引擎，负责本机的容器创建和管理工作。

1.正确安装、配置和启动了上述关键进程的节点可以在运行期间动态增加到Kubernetes集群中

2.默认情况下kubelet会向Master注册自己，定时向Master汇报自身的情报，例如操作系统、Docker版本、机器的CPU和内存情况，以及当前有哪些Pod在运行等

3.Master获知每个Node的资源使用情况后，会实现高效均衡的资源调度策略（多资源会增加pod，少资源会减少pod）

4.某个Node在超过指定时间不上报信息时，Master会把它判定为“失联”，Node的状态被标记为不可用（Not Ready），该节点上的pod会转移到其它运行正常的Node上。

5.查看集群中有多个个Node

  1. # kubectl get nodes

6.查看某个Node的详细信息

  1. # kubectl describe node <node_name>

1.4.3 Pod

Pod是Kubernetes最重要的基本概念，最小运行单元。

每个Pod都有一个特殊的被称为“根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器。

Pod的组成

pod这样特殊组成结构的意义？（Pause容器存在的意义？）

  1. 引入业务无关并且不易死亡的Pause容器作为Pod的根容器，以它的状态代表整个容器组的状态，通过判定Pause容器状态来判定Pod容器是否存活
  2. Pod里的多个业务容器共享Pause容器的IP，共享Pause容器挂接的Volume，这样既简化了密切关联的业务容器之间的通信问题，也很好地解决了它们之间的文件共享问题。

Kubernetes为每个Pod都分配了唯一的IP地址，称之为PodIP，一个Pod里的多个容器共享PodIP地址。

Kubernetes要求底层网络支持集群内任意两个Pod之间的TCP/IP直接通信，这通常采用虚拟二层网络技术来实现，例如Flannel、OpenvSwitch等，因此，在Kubernetes里，一个Pod里的容器与另外主机上的Pod容器能够直接通信。

Pod其实有两种类型：

  • 普通的Pod

    一旦被创建，就会被放入etcd中存储，进而被Master调度到某个Node上绑定（Binding），随后被kubelet进程实例化成一组相关的Docker容器并启动，之后kubelet会将该pod的情况定时汇报给Master

  • 静态Pod（StaticPod）

    没有被存放到Kubernetes的etcd存储中，而是被存放在某个具体的Node上的一个具体文件中，并且只有在此Node上启动、运行。

Pod、容器与Node的关系

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

1.4.4 Label

Label（标签）是Kubernetes系统中另外一个核心概念。一个Label是一个key=value的键值对，其中key与value由用户自己指定。Label可以被附加到各种资源对象上，例如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上。Label通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除。

可以通过给指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能，以便灵活、方便地进行资源分配、调度、配置、部署等管理工作。例如，部署不同版本的应用到不同的环境中；监控和分析应用（日志记录、监控、告警）等。

常用Label示例：

  • 版本标签：”release”:”stable”、”release”:”canary”。
  • 环境标签：”environment”:”dev”、”environment”:”qa”、”environment”:”production”。
  • 架构标签：”tier”:”frontend”、”tier”:”backend”、”tier”:”middleware”。
  • 分区标签：”partition”:”customerA”、”partition”:”customerB”。
  • 质量管控标签：”track”:”daily”、”track”:”weekly”。

Label相当于我们熟悉的“标签”。给某个资源对象定义一个Label，就相当于给它打了一个标签，随后可以通过LabelSelector（标签选择器）查询和筛选拥有某些Label的资源对象，Kubernetes通过这种方式实现了类似SQL的简单又通用的对象查询机制。

LabelSelector可以被类比为SQL语句中的where查询条件，例如，name=redis-slave这个LabelSelector作用于Pod时，可以被类比为select * from pod where pod’sname =‘redis-slave’这样的语句。

当前有两种LabelSelector表达式：基于等式的（Equality-based）和基于集合的（Set-based），

Equality-based 采用等式类表达式匹配标签，下面是一些具体的例子。

  • name=redis-slave：匹配所有具有标签name=redis-slave的资源对象。
  • env!=production：匹配所有不具有标签env=production的资源对象，比如env=test就是满足此条件的标签之一。

Set-based 使用集合操作类表达式匹配标签，下面是一些具体的例子。

  • name in（redis-master,redis-slave）：匹配所有具有标签name=redis-master或者name=redis-slave的资源对象。
  • name notin（php-frontend）：匹配所有不具有标签name=php-frontend的资源对象。

1.4.5 Replication Controller

RC声明某种Pod的副本数量在任意时刻都符合某个预期值，所以RC的定义包括如下

  • Pod期待的副本数量
  • 用于筛选目标Pod的Label Selector。

修改RC的副本数量来实现Pod的动态缩放（Scaling）

  1. kubectl scale rc redis-slave --replicas=3

ReplicaSet，官方解释其为“下一代的RC”。ReplicaSet与RC当前的唯一区别是，Replica Sets支持基于集合的Labelselector（Set-based selector），而RC只支持基于等式的LabelSelector（equality-based selector），这使得ReplicaSet的功能更强。

ReplicaSet与Deployment这两个重要的资源对象逐步替代了之前RC的作用，是Kubernetes1.3里Pod自动扩容（伸缩）这个告警功能实现的基础，也将继续在Kubernetes未来的版本中发挥重要的作用。

总结ReplicaSet的一些特性与作用

  • 在大多数情况下，通过定义一个RC实现Pod的创建及副本数量的自动控制。
  • 在RC里包括完整的Pod定义模板。
  • RC通过Label Selector机制实现对Pod副本的自动控制。
  • 通过改变RC里的Pod副本数量，可以实现Pod的扩容或缩容。
  • 通过改变RC里Pod模板中的镜像版本，可以实现Pod的滚动升级。

1.4.6 Deployment

Deployment是Kubernetes在1.2版本中引入的新概念，用于更好地解决Pod的编排问题。

Deployment的典型使用场景有以下几个:

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

查看Deployment的信息：

  1. kubect get deployment
  2. DESIRED：Pod副本数量的期望值，即在Deployment里定义的Replica。
  3. CURRENT：当前Replica的值，实际上是Deployment创建的ReplicaSet里的Replica值，这个值不断增加，直到达到DESIRED为止，表明整个部署过程完成。
  4. UP-TO-DATE：最新版本的Pod的副本数量，用于指示在滚动升级的过程中，有多少个Pod副本已经成功升级。
  5. AVAILABLE：当前集群中可用的Pod副本数量，即集群中当前存活的Pod数量。

1.4.7 Horizontal Pod Autoscaler

1.4.8 StatefulSet

1.4.9 Service

1.4.10 Job

1.4.11 Volume

1.4.12 Persistent Volume

1.4.13 Namespace

1.4.14 Annotation

1.4.15 ConfigMap

1.4.16 小结

第2章　Kubernetes安装配置指南

第3章　深入掌握Pod

第4章　深入掌握Service

第5章　核心组件运行机制

第6章　深入分析集群安全机制

第7章　网络原理

第8章　共享存储原理

第9章　Kubernetes开发指南

第10章　Kubernetes集群管理

第11章　Trouble Shooting指导

第12章　Kubernetes开发中的新功能