前言：

在学习BIP过程中，了解到了许多需要使用的环境组件，因此学习是必不可少的。其中K8S为环境中重要的一环，学习K8S对于了解整个系统的组成有着至关重要的作用。学习过程将以K8S的发展历史，概念，构成，优势，原理，不足以及未来发展几个方面为脉络对K8S进行了解。

一、K8S是什么

Kubernetes项目由Google公司在2014年启动。Kubernetes建立在Google公司超过10多年的运维经验基础之上，Google所有的应用都运行在容器上，然后与社区中最好的想法和实践相结合,Kubernetes是目前最受欢迎的容器平台。
Kubernetes是一套容器集群管理系统，是一个开源平台，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。Kubernetes拥有自动包装、自我修复、横向缩放、服务发现、负载均衡、自动部署、升级回滚、存储编排等特性。Kubernetes与DevOps、微服务等相辅相成，密不可分。

二、K8S的发展

Kubernetes是一套容器集群管理系统，谈论到Kubernetes的发展离不开容器的发展，接下来将从三个方面来对容器使用历程进行阐述。

1）开发过程的发展

1、瀑布式开发

瀑布式开发瀑布模型是一种广泛采用的项目开发过程。
其核心思想在于，按照一定的工序让问题变得有迹可循，将软件开发过程划分为需求分析、需求定义、概要设计、详细设计、编码、系统测试、验收测试、维护这8个阶段。各个阶段自上而下，互相衔接，就像是瀑布流水一样。

瀑布式开发的缺点也是显而易见的
（1）由于阶段的划分比较独立，上一个阶段的成果未必适合下一个阶段。
（2）计划非常死板。任何一个环节出现延误，都会影响后续阶段。
（3）交付周期太长，过程风险难以控制且不能及时响应变化。
（4）反馈回路太长，几乎到最后阶段才能发现瀑布式开发是否适用。
容器技术在这一代开发过程中没有发挥太大作用，即使使用，也局限于最后一两个阶段。有容器固然很好，但由于瀑布模型的先天劣势，容器对它帮助不大，收效甚微。

2、敏捷式开发

敏捷式开发是一种以用户需求为核心，通过迭代、循序渐进完成软件开发的方法。它的核心在于，整个项目被拆分为多个拥有联系但相对独立的子项目。
敏捷式开发的交付周期适中，反馈回路适中，很多开发团队会使用持续集成时间贯穿整个过程。容器技术开始在这一开发过程中显示出一定的作用。
有效利用它会带来可见的良性改观，但容器技术并未起决定性作用。

3、DevOps

DevOps一词来自Development和Operation的组合，突出了软件开发人员和运维人员的沟通合作，通过自动化流程来使软件构建、测试与发布更加快捷、频繁和可靠。伴随着全链路监控，DevOps能够真正做到更快捷的持续交付，并拥有更短的反馈回路。相对于敏捷式开发，DevOps响应变化的速度更快，对风险更可控。
作为自动化部署的一大利器，Kubernetes高效的部署、卓越的集群管理、强大的反馈监控等，能够给DevOps打下坚实的基础，Kubernetes本身并不是DevOps，而DevOps也不是Kubernetes。它们是相辅相成的。

2)应用架构的发展

应用架构大致经历了单体架构、多层架构和微服务架构3个阶段。

1、单体架构与多层架构

单体架构是指部署在单台物理机上的应用架构。
在软件架构中，还有一些经典的分层架构，如经典的3层架构从上到下依次由用户界面层、业务逻辑层与数据访问层组成。
在分层架构的时代，多数企业的系统往往较简单，用户量也不大，而这种分层架构在本质上是单体架构的数据库管理系统
单体架构的缺点非常明显，包括但不限于以下这些。
• 开发效率低：所有团队或开发人员都在修改同一个项目的代码，代码冲突概率极大，仅解决冲突都令人应接不暇。
• 代码维护难：代码的功能耦合在一起，稍不注意就有分析遗漏或改到不想改的功能。另外，还有各种历史开关与成堆的遗弃代码，这导致分析难度极大，无用功较多。
• 部署不灵活：构建时间长，有任何小修改就必须重新构建整个项目，这个过程往往很长。部署麻烦，部署后的重启耗时太长。
• 健壮性极低：一个微不足道的小问题就可以造成整个应用程序的瘫痪。
• 扩展性极差：动态扩容困难，无法满足高并发情况下的业务需求

2、微服务架构

微服务是指拥有独立业务意义的小型服务，简单地说，微服务就是提交量很微小的服务。
微服务对部署与监控提出了更高的要求，而能满足这些要求的，正是容器技术。容器技术使开发环境与生产环境完全相同，解决微服务对机器的诉求问题。

3）部署/打包的发展

1、物理机和虚拟机

物理机就是由硬件组成的实体计算机，在这台实体机器上安装操作系统，并直接部署应用的运行环境及应用程序。假设其中有一个应用发生异常或者管理员执行了误操作，可能就会直接导致服务器崩溃。
要克服直接使用物理机的各个弊端，就要引入虚拟化技术，将一台计算机虚拟化为多台逻辑计算机。在一台物理机上同时运行多台逻辑计算机，每台逻辑计算机可运行不同的操作系统，并且应用程序可以在相互独立的空间内运行，互不影响。

2、容器

容器是一种新兴的虚拟化方式。在传统虚拟机技术中，首先虚拟出一套硬件，然后运行一个完整的操作系统，最后才运行应用依赖项和应用程序。而容器并不需要这些，它可以让应用程序直接运行于宿主内核，自己本身没有内核，也不需要硬件虚拟。

三、k8s的构成

主要有master节点和node节点构成。master节点下发指令给node，node进行执行操作。node节点是一个虚拟机或者物理机器，包含运行pod所需的服务。

master节点：

主要由Kube-apiserver，etcd，Controller-manager，scheduler构成。

Kube-apiserver

k8s API Server提供了k8s各类资源对象（pod,RC,Service等）的增删改查及watch等HTTP Rest接口，是整个系统的数据总线和数据中心。

1. 提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更)；
2. 提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接操作etcd）;
3. 提供准入控制的功能；
4. 拥有完备的集群安全机制.

etcd

数据库，储存元数据信息，比如各个节点的当前状态

Controller-manager

Controller Manager 由 kube-controller-manager 和 cloud-controller-manager 组成，是 Kubernetes 的大脑，它通过 apiserver 监控整个集群的状态，并确保集群处于预期的工作状态。

scheduler

Scheduler 在整个系统中承担了“承上启下”的重要功能。“承上”是指它负责接受 Controller Manager 创建的新 Pod，为其安排 Node；“启下”是指安置工作完成后，目标 Node 上的 kubelet 服务进程接管后续工作。
kube-scheduler 的功能是为还没有和任何 Node 节点绑定的 Pods 逐个地挑选最合适 Pod 的 Node 节点，并将绑定信息写入 etcd 中。

node节点：

主要由kubelet，Kube-proxy，容器运行时（docker）构成

kubelet

• kubelet是在每个Node上都运行的主要代理进程。
• kubelet以PodSpec为单位来运行任务，PodSpec是一种描述Pod的YAML或JSON对象。
• kubelet负责维护容器的生命周期，同时也负责存储卷（volume）等资源的管理。
• 每个Node上的kubelet会定期调用Master节点上API Server进程的REST接口，报告自身状态。API Server进程接收这些信息后，会将Node的状态信息更新到etcd中。kubelet也通过API Server进程的Watch接口监听Pod信息，从而对Node上的Pod进行管理。

Kube-proxy

kube-proxy主要用于管理Service的访问入口，包括从集群内的其他Pod到Service的访问，以及从集群外访问Service。

容器运行时（docker）

容器运行时是负责运行容器的软件。Kubernetes支持多种运行时，包括Docker、containerd、cri-o、rktlet以及任何基于Kubernetes CRI（容器运行时接口）的实现。

一些其他的关键组件：

pod：调度的最小单位。由docker和pause容器组成，pause容器存放pod中的所有docker，用于维护容器网络不会出现异常。一般来说，用户不会直接创建Pod，而是创建控制器，让控制器来管理Pod。
deployment控制器：维持pod数量
service：把多个pod抽象为一个服务
dns：把service抽象出的服务虚拟IP生成域名方便互相访问
ingress：将虚拟IP映射到公网上供用户使用。Ingress并不是某种服务类型，可以充当多个Service组件的统一入口。Ingress支持将路由规则合并到单个资源中，可以通过同一域名或IP地址下不同的路径来访问不同的Service组件

组件间的基本交互流程

以Pod的创建为例，当使用kubectl创建Pod时，会相继发生以下事件

具体发生的事件如下。

1. kubectl命令将转换为对API Server的调用。
2. API Server验证请求并将其保存到etcd中。
3. etcd通知API Server。
4. API Server调用调度器。
5. 调度器决定在哪个节点运行Pod，并将其返回给API Server。
6. API Server将对应节点保存到etcd中。
7. etcd通知API Server。
8. API Server在相应的节点中调用kubelet。
9. kubelet与容器运行时API发生交互，与容器守护进程通信以创建容器。
10. kubelet将Pod状态更新到API Server中。
11. API Server把最新的状态保存到etcd中。

小结

• Kubernetes集群主要由Master和Node组成。Master管理Node，Node管理容器。
• Master的主要组件分别为kube-apiserver（负责实际操作）、etcd（负责存储）、kube-scheduler（负责Pod调度）、kube-controller-manager（负责对象管理）。
• Node的主要组件分别为kubelet（值守进程）、kube-proxy（负责服务发现）和容器运行时（负责操作容器）。
• Kubernetes以Pod为最小单位进行调度、伸缩并共享资源、管理生命周期。
• 控制器中定义了Pod的部署方式，如有多少个副本、需要在哪种Node上运行等。根据不同的业务场景，Kubernetes提供了多种控制器，如ReplicationController、ReplicaSet控制器、Deployment控制器、StatefulSet控制器、DaemonSet控制器、Job控制器和CronJob控制器。
• Service是内部负载均衡器中的一种组件，会将相同功能的Pod在逻辑上组合到一起，让它们表现得如同一个单一的实体。
• Kubernetes定义了自己的存储卷抽象，允许Pod中的所有容器共享数据，在Pod终止之前一直保持可用。而持久存储卷是一种更健壮的抽象机制，不依赖于Pod的生命周期。
• Label是一种语义化标签，可以附加到Kubernetes对象上，对它们进行标记或划分。

四、K8S能做到什么，做不到什么以及未来前景

K8s容器优势总结：

• 快速创建/部署应用：与VM虚拟机相比，容器镜像的创建更加容易。
• 持续开发、集成和部署：提供可靠且频繁的容器镜像构建/部署，并使用快速和简单的回滚(由于镜像不可变性)。
• 开发和运行相分离：在build或者release阶段创建容器镜像，使得应用和基础设施解耦。
• 开发，测试和生产环境一致性：在本地或外网（生产环境）运行的一致性。
• 云平台或其他操作系统：可以在 Ubuntu、RHEL、 CoreOS、on-prem、Google Container Engine或其它任何环境中运行。
• 松耦合，分布式，弹性，微服务化：应用程序分为更小的、独立的部件，可以动态部署和管理。
• 资源隔离
• 资源利用：更高效

K8s不能做到的：

• Kubernetes并不是传统的PaaS（平台即服务）系统
• Kubernetes不提供中间件（如message buses）、数据处理框架（如Spark）、数据库(如Mysql)或者集群存储系统(如Ceph)作为内置服务。但这些应用都可以运行在Kubernetes上面。
• Kubernetes不部署源码不编译应用。持续集成的 (CI)工作流方面，不同的用户有不同的需求和偏好的区域，因此，我们提供分层的 CI工作流，但并不定义它应该如何工作。
• Kubernetes不提供或授权一个全面的应用程序配置语言/系统（例如，jsonnet）。
• Kubernetes不提供任何机器配置、维护、管理或者自修复系统。
• Kubernetes运行在应用级别而不是硬件级，因此提供了普通的Paas平台提供的一些通用功能，比如部署，扩展，负载均衡，日志，监控等。这些默认功能是可选的。

前景

在翻看网上以及书中的资料后，资料对K8S未来的发展大多是过时的或者是没有提及的，但是正在研发的BIP的使用中K8S这个框架却还是在其中占据着重要位置，因此本小白对于K8S的前景还是有着乐观的态度。