Kubernetes技术与架构（二）
1 前言
1.1 CNCF
1.2 云原生
1.3 公有云服务
1.4 私有云服务
1.5 混合云服务
2 Kubernetes定义
2.1 基本概念
2.2 架构演进
2.2.1 传统部署（Traditional deployment ）
2.2.2 虚拟化部署（Virtualized deployment）
2.2.3 容器化部署（Container deployment）
2.3 使用场景
目前在IT基础设施建设领域中，容器化是绑定与运行业务应用的最佳方式。在生产环境中，企业需要管理这些运行着应用的容器，并且需要保证这些容器不会出现宕机的情况，例如，当其中一个容器宕机，另外一个容器需要自动地取代已宕机容器的工作从而继续提供服务。因此，容器化是一种简单易用而且具备高可用性的部署方式。
Kubernetes能为企业提供一个可弹性地运行分布式系统的框架，该框架核心是自动化地扩展业务应用的规模以及对部署的应用执行失败转移的策略。以上这些部署策略被称之为金丝雀部署，其提供以下的使用场景：
-
服务发现以及负载均衡，Kubernetes使用DNS域名或者IP地址对外发布服务，如果一个容器过载，则使用负载均衡策略将部分流量均衡地分发到其他的同等容器，从而保证部署系统的稳定性。
-
存储编排，Kubernetes能自动地装载一个用户指定的存储系统，系统类型包括本地存储、公有云存储等等。
-
自动发布与自动回滚，用户能使用kubernetes配置容器的目标部署状态，并且容器在不同部署状态之间的转换率可控，也就是，Kubernetes能根据用户配置自动化地创建新的部署容器，也可以自动化地删除已部署的容器，并且将已删除容器的占用资源适配给新建的部署容器。
-
自动装箱，在集群环境中，kubernetes能根据用户配置的每个容器占用处理器资源或者内存资源的比例，自动化在这些分布式的服务器节点中运行容器化的任务。这种自动装箱的部署模式能充分利用系统资源。
-
自愈，Kubernetes能重启失败的容器、替换容器以及关闭对自愈系统检测没响应的容器，只对外开放自愈系统检测正常的容器。
-
秘钥的配置与管理，Kubernetes能存储与管理敏感的信息，例如密码、鉴权票据以及SSH秘钥对等，用户能在不需要重新构建容器镜像、也不需要在配置中暴露秘钥的情况下部署以及更新秘钥、配置项。
2.4 使用约束
Kubernetes不是传统意义上的PAAS平台，因其运行在虚拟化的容器层而不是运行在物理硬件层，所以Kubernetes也提供了一些与PAAS相同的通用能力，例如，部署、扩展以及负载均衡，同时也提供了集成日志、监控以及告警的通用能力。然而，Kubernetes不是一个整体不可分割的集成系统，其提供的这些通用能力是可选的、插件化的，用户可以根据实际的业务应用需求，灵活地使用Kubernetes提供的组件、插件构建自身的业务平台。
根据Kubernetes平台的特征，具有如下的限制与约束：
-
Kubernetes不限制所支持的应用类型，其设计目标是支持各种不同类型的工作负载，例如有状态、无状态以及数据处理等类型的工作负载。如果一个应用能运行在容器中，那么这个应用也能很好地运行在Kubernetes中。
-
Kubernetes不支持源代码直接构建应用，持续集成、持续发布以及持续部署相关的工作流程是由企业组织文化及其实际的业务与技术需求决定的。
-
Kubernetes不提供应用级别的服务，例如，中间件（消息总线）、数据处理框架（Spark）、数据库（MySQL）、缓存以及集群存储系统（Ceph）等服务，但是这些服务可以运行在Kubernetes中，并且能被运行在Kubernetes中其他应用访问。
-
Kubernetes不对日志、监控以及告警相关方案做具体的规定，仅提供一些架构集成的方法、机制去收集、导出统计信息。
-
Kubernetes既不提供也不委托其他的配置系统，仅提供声明式的API，其可以与任何形式的声明式规范集成。
-
Kubernetes既不提供也不采纳任何综合了机器配置、运维、管理以及自愈相关的系统。
实际上，Kubernetes不是一个严格意义上的编排系统，技术上对编排的定义是ABC类型的工作流程：先处理A，再处理B，最后处理C。但是，Kubernetes是由一组独立的、可编排的控制过程构成，这些控制过程能持续地促使一个当前状态向目标状态转变，也就是，如何从A状态转变为C状态不重要，这些状态的转变不需要集中式控制，这些松耦合的去中心化的机制让Kubernetes变得更易于使用、功能更强大、更具鲁棒性、更具弹性可伸缩以及更具可扩展性。
3 Kubernetes架构
Kubernetes的总体架构是一个分布式的集群架构，由一组工作节点组成，在工作节点上运行容器化部署的应用，而每个集群最小需要具备一个工作节点。本章节主要是描述Kubernetes集群架构与集群架构涉及到的关键组件。
3.1 集群架构
Kubernetes的集群架构如下图所示：
如上图所示，Node标识一个台物理机器，代表一个工作节点，Kubernetes在每个Node上运行一批Pods，而每个Pod装载着容器化部署的应用，每个Pod是Kubernetes实行弹性化资源调度的单元。其中，Control Plane（控制面）以及Node是分布式地运行在多台物理机器节点的集群中，其目的是为Kubernetes集群提供容错机制以及高可用性。
3.2 控制面（Control Plane）组件
Kubernetes集群架构中的控制面组件主要是为集群作出全局决策（例如资源调度），检测或者响应集群事件（例如启动一个新的Pod）。
3.2.1kube-apiserver
API server（kube-apiserver）是控制面中的一个组件，该组件主要负责暴露Kubernetes集群中的所有API接口，这些API接口主要提供给集群外部访问。Kube-apiserver支持水平扩展，也就是，可以部署多个Kube-apiserver实例，这些实例可以使用负载均衡策略对外提供接口访问的服务。
3.2.2etcd
etcd是一个提供一致性以及高可用性存储服务的key-value存储数据库，Kubernetes使用etcd存储集群后端的所有数据。为了数据的安全，需要及时或者周期性地备份etcd中的数据。
3.2.3kube-scheduler
kube-scheduler主要是负责Kubernetes集群中的资源调度，监视Pod的创建事件，为还没有分配Node的Pod找到一个合适的Node运行新建的Pod。调度器作出调度决策需要考虑的因素包括：单个或者整体资源需求、软件/硬件/策略的约束、资源相关度、数据位置、交互式工作负载的干涉、截止日期。
3.2.4kube-controller-manager
kube控制器管理器，主要是负责管理Kubernetes集群中所有的控制器进程。逻辑上，每个控制是一个独立的进程，但是Kubernetes为了降低系统的复杂度，把这些控制器编译成一个二进制文件集中运行在一个进程中。这些控制器的类型包括：
-
节点控制器（Node controller），主要负责通知与响应Node的宕机事件
-
任务控制器（Job controller），主要负责监视单次任务的Job对象，然后创建一个Pod或者多个Pod运行这些任务直到任务完成
-
端点控制器（Endpoints controller），发布Endpoints类型的对象，该类型的对象主要是用于连接Pod与服务
-
服务账号以及票据控制器（Service Account & Token controllers），为新命名空间创建默认账号或者用于API访问的票据
3.2.5cloud-controller-manager
云控制器管理器可以嵌入指定云的控制逻辑到Kubernetes集群中，也就是，该组件可以把Kubernetes集群连接到指定的云提供商的标准API中，连接成功后，使用指定的云提供商的标准API可以访问Kubernetes集群的API服务。与kube控制器管理器一样，云控制器管理器也是将多个控制器编译成一个二进制文件集中运行在一个进程中，这些控制器的类型包括：
-
节点控制器（Node controller），为指定云检测停止响应的Node节点
-
路由控制器（Route controller），设置指定云与Kubernetes集群之间的路由信息
-
服务控制器（Service controller），创建、更新、删除指定云与Kubernetes集群之间的负载均衡信息
3.3 节点（Node）组件
节点组件运行在Kubernetes集群的每个节点中，其主要负责维护运行中的Pod以及为Kubernetes提供运行时的环境。
3.3.1kubelet
kubelet是一个节点代理组件，运行在Kubernetes集群的每个节点中，其主要负责保证容器能正常运行在Pod中。Kubelet主要是根据Pod对应的具体描述文件（PodSpecs）去维护Pod的正常运行状态，并且确保Pod处于健康的运行状态之中。
3.3.2kube-proxy
kube-proxy是一个网络代理组件，运行在Kubernetes集群的每个节点中，是Kubernetes服务中的一部分。Kube-proxy维护了集群中节点之间的网络通讯规则，这些规则允许Pod提供的服务在Kubernetes集群内外都可以使用网络实行访问。Kube-proxy默认是使用操作系统的网络栈实行网络流量的传输，否则，将使用自身的功能实行网络流量的传输。
（未完待续）