一、Kubernetes简介

一、背景

1、部署方式的变迁

• 传统时代的部署
  • 在物理服务器上运行应用程序
  • 无法为应用程序定义资源边界
  • 导致资源分配问题

例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况， 结果可能导致其他应用程序的性能下降。 一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展， 并且维护许多物理服务器的成本很高。

• 虚拟化部署时代：
  • 作为解决方案，引入了虚拟化
  • 虚拟化技术允许你在单个物理服务器的 CPU 上运行多个虚拟机（VM）
  • 虚拟化允许应用程序在 VM 之间隔离，并提供一定程度的安全
  • 一个应用程序的信息 不能被另一应用程序随意访问。
  • 虚拟化技术能够更好地利用物理服务器上的资源
  • 因为可轻松地添加或更新应用程序 ，所以可以实现更好的可伸缩性，降低硬件成本等等。
  • 每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

缺点：虚拟层冗余导致的资源浪费与性能下降

• 容器部署时代：

  • 容器类似于 VM，但可以在应用程序之间共享操作系统（OS）。
  • 容器被认为是轻量级的。
  • 容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。
  • 由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。

• 容器优势：

  • 敏捷性: 敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
  • 及时性： 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性），支持可靠且频繁的 容器镜像构建和部署。
  • 解耦性： 关注开发与运维的分离：在构建/发布时创建应用程序容器镜像，而不是在部署时。 从而将应用程序与基础架构分离。
  • 可观测性： 可观察性不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
  • 跨平台： 跨开发、测试和生产的环境一致性：在便携式计算机上与在云中相同地运行。
  • 可移植： 跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、 Google Kubernetes Engine 和其他任何地方运行。
  • 简易性： 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
  • 大分布式： 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分， 并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
  • 隔离性： 资源隔离：可预测的应用程序性能。
  • 高效性： 资源利用：高效率和高密度

• K8S之前：

  • 10台服务器资源：可以部署25个服务+15中间件

• K8S之后：

  • 10台服务器：上百个应用了。

• k8s管理10几台服务器。可以进行动态资源规划

2、使用容器我们需要解决的问题

• 弹性的容器化应用管理
• 强大的故障转移能力
• 高性能的负载均衡访问机制
• 便捷的扩展
• 自动化的资源监测
• .....

3、为什么用Kubernetes

容器是打包和运行应用程序的好方式。在生产环境中，你需要管理运行应用程序的容器，并确保不会停机。 例如，如果一个容器发生故障，则需要启动另一个容器。如果系统处理此行为，会不会更容易？
这就是 Kubernetes 来解决这些问题的方法！ Kubernetes 为你提供了一个可弹性运行分布式系统的框架。linux之上的一个服务编排框架；
Kubernetes 会满足你的扩展要求、故障转移、部署模式等。 例如，Kubernetes 可以轻松管理系统的 Canary 部署。

Kubernetes 为你提供：

• 服务发现和负载均衡

  Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。

• 存储编排

  Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。

• 自动部署和回滚

  你可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态 更改为期望状态。例如，你可以自动化 Kubernetes 来为你的部署创建新容器， 删除现有容器并将它们的所有资源用于新容器。

• 自动完成装箱计算

  Kubernetes 允许你指定每个容器所需 CPU 和内存（RAM）。 当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。

• 自我修复

  Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的 运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。

• 密钥与配置管理

  Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥

• .......

4、市场份额

1、容器

2、服务编排

二、简介

Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。

名称 Kubernetes 源于希腊语，意为“舵手”或“飞行员”。Google 在 2014 年开源了 Kubernetes 项目。 Kubernetes 建立在 [Google 在大规模运行生产工作负载方面拥有十几年的经验](https://research.google/pubs/pub43438) 的基础上，结合了社区中最好的想法和实践。

• Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统。
• Kubernetes 在容器级别而不是在硬件级别运行
• 它提供了 PaaS 产品共有的一些普遍适用的功能， 例如部署、扩展、负载均衡、日志记录和监视。
• 但是，Kubernetes 不是单体系统，默认解决方案都是可选和可插拔的。 Kubernetes 提供了构建开发人员平台的基础，但是在重要的地方保留了用户的选择和灵活性。

Kubernetes：

• 不限制支持的应用程序类型。 Kubernetes 旨在支持极其多种多样的工作负载，包括无状态、有状态和数据处理工作负载。 如果应用程序可以在容器中运行，那么它应该可以在 Kubernetes 上很好地运行。

• 不部署源代码，也不构建你的应用程序。 **持续集成(CI)、交付和部署（CI/CD）**工作流取决于组织的文化和偏好以及技术要求。

• 不提供应用程序级别的服务作为内置服务，例如中间件（例如，消息中间件）、 数据处理框架（例如，Spark）、数据库（例如，mysql）、缓存、集群存储系统 （例如，Ceph）。这样的组件可以在 Kubernetes 上运行，并且/或者可以由运行在 Kubernetes 上的应用程序通过可移植机制（例如， 开放服务代理）来访问。

• 不要求日志记录、监视或警报解决方案。 它提供了一些集成作为概念证明，并提供了收集和导出指标的机制。

• 不提供或不要求配置语言/系统（例如 jsonnet），它提供了声明性 API， 该声明性 API 可以由任意形式的声明性规范所构成。RESTful；写yaml文件

• 不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。

• 此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。 编排的技术定义是执行已定义的工作流程：首先执行 A，然后执行 B，再执行 C。 相比之下，Kubernetes 包含一组独立的、可组合的控制过程， 这些过程连续地将当前状态驱动到所提供的所需状态。 如何从 A 到 C 的方式无关紧要，也不需要集中控制，这使得系统更易于使用 且功能更强大、系统更健壮、更为弹性和可扩展。

容器管家：

• 安装了很多应用——>qq电脑管家。（自动杀垃圾，自动卸载没用东西....）
• 机器上有很多容器——>kubernete容器的管家。（容器的启动停止、故障转义、负载均衡等）

二、Kubernetes安装

一、集群原理

1、master-node架构 （主管理从）、

master节点主要是管理node，真正应用在node节点上工作

程序员使用UI(界面)或者CLI(命令行)操作k8s集群的master，就可以知道整个集群的状况。 master节点给node节点安排任务，决定node节点要干什么活 node节点出现故障或者其他情况也需要给master节点汇报 每个node干自己的活，互不影响

2、工作原理

master节点（其他名字：Control Plane【控制面板】）：master节点控制整个集群

• master节点上有一些核心组件：

  • Controller Manager：控制管理器
  • etcd：键值数据库（redis）【记账本，记事本】
  • scheduler：调度器
  • api server：api网关（所有的调用都需要通过api-server，api网关是master的唯一入口）

• node节点（worker工作节点）上的核心组件：

  • kubelet（监工）：每一个node节点上必须安装的组件，监工每天与master节点保持通信(联系)，在默认情况下kubelet会向master注册自己，代表自己所在的node节点是master集群管理的一员。node一旦被纳入集群管理范畴，kubelet就会定时向master汇报自身节点的情况，如主机CPU、内存使用情况，以及当前有哪些pod在运行等，这样，master就可以获得每个Node的资源使用情况，实现高效均衡的资源调度策略。某个Node节点在指定时间不上报信息时，会被master判定为失联，该node的状态就会被标记为不可用。
  • kube-proxy：代理。代理网络
  • pod：kubelet启动的一个应用，称为一个pod。pod是k8s的基本单位，pod是docker的一个再封装。一个pod可包含多个容器，一个pod代表一个基本的应用。

• 在k8s集群上部署一个应用的流程

  • 程序员：调用CLI（命令行）告诉master，我们现在要部署一个tomcat应用
  • 程序员的所有调用，都先去master节点的API网关。API网关是master的唯一入口，只负责接收请求
  • master的API server收到请求后交给master的controller-manager进行控制
  • controller-manager进行应用部署，会生成一次部署信息并封装起来。tomcat ->tomcat：6 暴露端口8080 等等，此时不会真正部署应用。
  • controller-manager生成的部署信息被记录到master节点的etcd中
  • master节点的scheduler（调度器）从etcd中拿到需要部署的应用，开始调度。看哪个node节点适合部署该应用
  • scheduler节点把算出来的调度信息再放到etcd中
  • 每一个node节点的kubelet（监工）随时与master节点保持联系的(不断给api-server发送请求获取最新数据)，所有节点的kubelet（监工）就会从master节点获取最新数据
  • 假设2号节点的kubelet（监工）最终收到了命令要部署应用
  • kubelet（监工）就run一个应用在当前node节点，并且给应用分配一个IP，随时通过api-server给master汇报当前应用的状态信息
  • 每个node节点上都有一个kube-proxy，它可以知道集群所有node的网络信息。只要node之间互相访问，kube-proxy网络代理就会自动计算，并进行流量转发。

下图和上图一样的，再理解一下

二、组件交互原理

• 让k8s部署一个tomcat
  • 0、开机默认所有节点的kubelet、master节点的schedule、controller-manager一直监听master节点的api-server发来的事件变化
  • 1、程序员使用命令行工具部署tomcat：kubectl create deploy tomcat --image=tomcat8（告诉master让集群使用tomcat8镜像部署一个tomcat应用
  • 2、kubectl 命令行发给api-server，api-server保存此次的创建信息到etcd
  • 3、etcd给api-server上报事件，说刚才有人给我里面保存了一个部署tomcat的信息
  • 4、controller-manager监听到api-server的事件：部署tomcat
  • 5、controller-manager处理部署tomcat的事件，并且controller-manager生成pod的部署信息
  • 6、controller-manager将生成的pod部署信息交给api-server，并且api-server保存到etcd
  • 7、etcd上报pod部署信息事件给api-server
  • 8、schedule监听到api-server中有新的pod部署信息事件，从api-server获取到每个node节点的资源信息并计算出该pod事件应该部署到哪个node节点，给此pod加部署节点(node)的标签，并存储到etcd
  • 9、所有node节点的kubelet一直在api-server监听schedule加过部署节点标签的pod事件
  • 10、所有node节点的kubelet判断监听到的事件是否需要自己处理，如果需要自己处理，kubelet 来run一个pod，并且汇报给master节点的api-server。