第5章 K8s

5.1 K8s基础

5.1.3 K8s核心特性

• K8s的主要特点：
  • 轻量级：下载后即可用；
  • 便携：可部署在公有云、私有云或混合云等任意环境；
  • 可扩展性：采用插件化的设计架构，每个模块都可插拔；
• K8s的核心功能：自动化的任务管理、对微服务架构体系的支撑以及最大化资源利用；
  
  • 自动化的任务管理：包括应用自动发布、自动恢复故障、弹性扩容以及滚动升级；
    
    • 应用自动发布功能：K8s以智能的方式将应用程序发布到数据中心的各个服务器上，减少传统的大量手工操作，如数据库配置、负载均衡配置、应用打包等；
    • 应用自动故障恢复功能：K8s保证应用持续被监控，在发生故障时及时重启，以保证系统能够持续提供服务，实现应用的高可用；
    • 应用的扩容缩容功能：K8s基于性能指标动态地扩容或缩容应用实例数量，以实现对业务波动的弹性支撑；
    • 应用的滚动升级功能：将应用逐个升级替换，逐渐完成整个应用集群的升级，以保证任务的不中断；
  • 对微服务架构体系的支撑：
    • 组件服务化特性是指把单体应用系统中的组件拆分成多个微小的服务。智能端点指的是拥有独立完整业务逻辑的微服务，它们从管道上获取请求消息，进行智能处理，然后产生处理后的应答消息再放回管道。傻瓜管道指的是连接微服务进行消息传递的通信机制，它们只负责消息的传送，不关心业务逻辑的处理。K8s的微服务管理机制就是对这些微服务特性的完美支撑。
    • K8s把服务的概念提升到机器之上，以支撑对微服务质量的精细化运营。对于用户来说，在使K8s的时候，完全不用关心底层的硬件、操作系统、系统资源等基础设施，而只要关注微服务本身的设计，以及微服务之间的调用关系，这样就能为不同的业务提供不同的精细化服务质量等级(SLA)。对于微服务上线之后的运维工作，K8s也希望运维人员将关注中心从应用如何发布转向业务级别的服务运维，关心业务运行指标，及时做出调整，为提供更精准的业务级别服务质量提供支持。
  • 最大化资源的利用率：使用智能调度算法充分利用数据中心的所有资源，在部署应用时科学规划、动态调整，从而最大化资源的利用率。

5.2 K8s的总体系统架构和核心资源对象

5.2.1 K8s的总体系统架构

• K8s是一个分布式系统，由一共Master节点和多个计算节点（Node）组成，其中Master负责整个集群的管理与控制，每个Node都会被Master分配一些工作负载（以容器的形式）执行并监控容器的运行状态；
  
  • Master节点主要包括4个功能组件：
    • API Server：提供集群总管和总线的功能，为集群内各个功能模块之间提供数据交互和通信功能，并将各任务的信息保存到etcd中；
    • Controller Manager：集群的管理控制中心，负责集群内各种资源的管理，当某个Node或容器发生故障时，Controller Manager会及时执行自动化修复流程；
    • Scheduler：将待调度的pod基于一定的调度算法和调度策略调度到集群中某个合适的Node上。
    • etcd：集群的中央数据库，保存集群内所有容器应用的运行状态、任务配置信息和各种事件信息等内容；
  • Node节点有2个代理组件，即Kubelet和Proxy
    • Kubelet：负责本机上各个容器的全生命周期管理，从创建开始，到运行状态的跟踪，再到销毁、删除或重启等工作；
    • Proxy：一个智能的负载均衡器，他是K8s核心Service概念的具体实现。Service是指将由容器组成的分布式应用封装起来形成的逻辑概念，Proxy主要功能就是将客户端对Service的访问请求转发到后端正确的容器上去。
  • 用户交互：
    • 用户与K8s集群有两种常见的交互模式：
      • 第一种是用户直接访问各个Node（容器运行在各个Node节点上）；
      • 用户给集群发送应用管理的控制指令，常见的请求包括创建容器、副本数量调整以及删除容器等；

5.2.2 K8s的核心资源对象

• 资源对象：资源对象是Kubernetes系统中最核心的管理单元，包括Node、Pod、RC、Service、Endpoint、Namespace等，所有的资源对象的定义和运行状态都保存在etcd数据库中，并可以进行增、删、改、查等操作。Kubernetes通过持续跟踪并对比etcd数据库中保存的“用户期望状态”与“实际运行状态”的差异，来实现自动控制和自动纠错等高级功能。

• 声明型配置：Kubernetes创新性地使用一种“声明型”的配置
  供用户进行描述。相对而言，在传统的工厂运维工作中，运维工程师使用的多是“指令型”的配置方式，并常伴随着各种自动化脚本。指令型配置的核心是运维人员必须“知道”在哪些机器上启动或停止哪些应用程序，与机器深度绑定。而在声明型的配置中，Kubernetes希望用户不用再关心机器，而只要关心应用本身。换句话说，Kubernetes只需用户给出一个服务要多少实例来支撑，以及监听的端口号等“需求”即可，至于这些应用实例应该在哪台机器上进行创建和运行，无须用户再操心了。声明型配置的内容基本上等同于用户对其微服务的运行需求，是一种完全面向业务需求的配置，而且其描述格式简单易懂，能够大大减轻运维的人工操作，提高业务研发的效率。
  

• K8s的4个核心资源对象：

  • Pod：K8s中最小的应用管理单元是Pod而不是容器，一个Pod可包含多个容器，同一个Pod内的容器拥有相同的IP地址，还可以共享存储卷(Volume)和网络栈(Network Stack)。同一个Pod内不同的容器使用不同的端口号提供服务；
  • RC(Replication Controller,副本控制器)：提供对一个或多个Pod副本的自动化管理工作，维护任意时刻运行的Pod副本数量都符合用户期望，K8s基于RC实现容器应用的自动化管理功能和高可用；
  • Service：在微服务架构里，一个微服务通常都是由应用的多个实例组成的，并且支持水平扩展的分布式服务。在Kubernetes系统中，应用的实例由Pod实现，应用的高可用性由RC提供。但是由于Pod以轻量级的容器作为载体，容器的状态可能发生动态变化，如切换机器、扩容缩容等，因此对于客户端应用来说，动态地发现所有提供服务的Po地址变得非常困难。Service提供的主要功能就是为客户端访问后端服务提供入口，并将客户端请求转发到多个Pod的代理服务器，解决微服务架构中核心的服务发现、服务路由、负载均衡等问题。也就是说，Service提供的是一种“智能”的负载均衡器的功能，因此，系统管理员无须手工设置额外的负载均衡器赖将客户端请求转发到各个应用实例上；
  • Label/Label Selector：Label相当于我们熟悉的“标签”，给某个资源对象定义一个Label，就相当于给它贴了一个标签，然后就可以用Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象，实现了一种简单通用的对象关联机制。

5.3 K8s的服务发现机制

• 服务发现机制是微服务架构里最重要的功能，也是微服务支撑平台必须实现的功能。如果服务发现没有实现，客户端应用将很难找到提供服务的应用访问地址，更困难的是，当后端服务运行过程地址发生了变化时，客户端应该如何重新访问；
• K8s提供集群内部和外部的服务发现机制，对于集群内部的客户端应用，K8s提供2种访问后端服务的方式，即“以环境变量形式”和“以虚拟DNS服务实现服务名到虚拟IP地址的解析”；
• 集群内服务发现机制1—环境变量：K8s在创建客户端应用时，直接将服务的信息以环境变量的方式注入容器内部环境中，
• 集群内服务发现机制2—虚拟DNS服务(SkyDNS)：SkyDNS将服务名与服务IP地址的对应关系记录为DNS记录，并提供客户端访问服务名时的IP地址解析服务。

5.3.3 从集群外访问服务

• 在物理环境下，K8s用物理机的端口号将Service暴露出去，使客户端应用可通过物理机的IP地址和端口号赖访问Service，Service映射到物理机的后端仍是虚拟Service的访问地址，而不是容器，Service仍需要完成将请求负载分发到各个容器的过程；
• 公有云环境下，将Service对外暴露要使用公有云提供的Load Balancer；