云原生 从docker、Jenkins、Kubernetes从入门到精通系列
1、部署方式的变迁
- 传统部署时代：
- 在物理服务器上运行应用程序
- 无法为应用程序定义资源边界
- 导致资源分配问题
例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况， 结果可能导致其他应用程序的性能下降。 一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展， 并且维护许多物理服务器的成本很高。
- 虚拟化部署时代：
- 作为解决方案，引入了虚拟化
- 虚拟化技术允许你在单个物理服务器的 CPU 上运行多个虚拟机（VM）
- 虚拟化允许应用程序在 VM 之间隔离，并提供一定程度的安全
- 一个应用程序的信息 不能被另一应用程序随意访问。
- 虚拟化技术能够更好地利用物理服务器上的资源
- 因为可轻松地添加或更新应用程序 ，所以可以实现更好的可伸缩性，降低硬件成本等等。
- 每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。
缺点：虚拟层冗余导致的资源浪费与性能下降
- 容器部署时代：
- 容器类似于 VM，但可以在应用程序之间共享操作系统（OS）。
- 容器被认为是轻量级的。
- 容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。
- 由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。
- 参照【Docker隔离原理- namespace 6项隔离（资源隔离）与 cgroups 8项资源限制（资源限制）】
容器优势：
- 敏捷性敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
- 及时性持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性），支持可靠且频繁的 容器镜像构建和部署。
- 解耦性：关注开发与运维的分离：在构建/发布时创建应用程序容器镜像，而不是在部署时。 从而将应用程序与基础架构分离。
- 可观测性：可观察性不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
- 跨平台：跨开发、测试和生产的环境一致性：在便携式计算机上与在云中相同地运行。
- 可移植：跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、 Google Kubernetes Engine 和其他任何地方运行。
- 简易性：以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
- 大分布式：松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分， 并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。
- 隔离性：资源隔离：可预测的应用程序性能。
- 高效性：资源利用：高效率和高密度
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 密钥。 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥 - .......
为了生产环境的容器化大规模应用编排，必须有一个自动化的框架。(or)系统
4、集群原理
4.1、master-node 架构
master 和 worker怎么交互?
master决定worker里面都有什么?
worker只是和master （API） 通信； 每一个节点自己干自己的活
程序员使用UI或者CLI操作k8s集群的master，就可以知道整个集群的状况。
4.2、工作原理
master节点（Control Plane【控制面板】）：master节点控制整个集群
master节点上有一些核心组件：
- Controller Manager：控制管理器
- etcd：键值数据库（redis）【记账本，记事本】
- scheduler：调度器
- api server：api网关（所有的控制都需要通过api-server）
node节点（worker工作节点）：
- kubelet（监工）：每一个node节点上必须安装的组件。
- kube-proxy：代理。代理网络
部署一个应用？
程序员：调用CLI告诉master，我们现在要部署一个tomcat应用
- 程序员的所有调用都先去master节点的网关api-server。这是matser的唯一入口（mvc模式中的c层）
- 收到的请求先交给master的api-server。由api-server交给controller-mannager进行控制
- controller-mannager 进行 应用部署
- controller-mannager 会生成一次部署信息。 tomcat --image:tomcat6 --port 8080 ,真正不部署应用
- 部署信息被记录在etcd中
- scheduler调度器从etcd数据库中，拿到要部署的应用，开始调度。看哪个节点合适，
- scheduler把算出来的调度信息再放到etcd中
- 每一个node节点的监控kubelet，随时和master保持联系的（给api-server发送请求不断获取最新数据），所有节点的kubelet就会从master
- 假设node2的kubelet最终收到了命令，要部署。
- kubelet就自己run一个应用在当前机器上，随时给master汇报当前应用的状态信息，分配ip
- node和master是通过master的api-server联系的
- 每一个机器上的kube-proxy能知道集群的所有网络。只要node访问别人或者别人访问node，node上的kube-proxy网络代理自动计算进行流量转发
下图和上图一样的，再理解一下
无论访问哪个机器，都可以访问到真正应用（Service【服务】）
4.3、原理分解
4.3.1、主节点（master）
快速介绍：
- master也要装kubelet和kubeproxy
- 前端访问（UI\CLI）：
- kube-apiserver：
- scheduler:
- controller manager:
- etcd
- kubelet+kubeproxy每一个节点的必备+docker（容器运行时环境）
4.3.2、工作节点（node）
快速介绍：
- Pod：
- docker run 启动的是一个container（容器），容器是docker的基本单位，一个应用是一个容器
- kubelet run 启动的一个应用称为一个Pod；Pod是k8s的基本单位。
- Pod是容器的一个再封装
- atguigu(永远不变) ==slf4j= log4j(类)
- 应用 ===== ==Pod== ======= docker的容器
- 一个容器往往代表不了一个基本应用。博客（php+mysql合起来完成）
- 准备一个Pod 可以包含多个 container；一个Pod代表一个基本的应用。
- IPod（看电影、听音乐、玩游戏）【一个基本产品，原子】；
- Pod（music container、movie container）【一个基本产品，原子的】
- Kubelet：监工，负责交互master的api-server以及当前机器的应用启停等，在master机器就是master的小助手。每一台机器真正干活的都是这个 Kubelet
- Kube-proxy：
其他：
5、组件交互原理
想让k8s部署一个tomcat？
0、开机默认所有节点的kubelet、master节点的scheduler（调度器）、controller-manager（控制管理器）一直监听master的api-server发来的事件变化（for ::）
1、程序员使用命令行工具： kubectl ； kubectl create deploy tomcat --image=tomcat8（告诉master让集群使用tomcat8镜像，部署一个tomcat应用）
2、kubectl命令行内容发给api-server，api-server保存此次创建信息到etcd
3、etcd给api-server上报事件，说刚才有人给我里面保存一个信息。（部署Tomcat[deploy]）
4、controller-manager监听到api-server的事件，是 （部署Tomcat[deploy]）
5、controller-manager 处理这个 （部署Tomcat[deploy]）的事件。controller-manager会生成Pod的部署信息【pod信息】
6、controller-manager 把Pod的信息交给api-server，再保存到etcd
7、etcd上报事件【pod信息】给api-server。
8、scheduler专门监听 【pod信息】 ，拿到 【pod信息】的内容，计算，看哪个节点合适部署这个Pod【pod调度过后的信息（node: node-02）】，
9、scheduler把 【pod调度过后的信息（node: node-02）】交给api-server保存给etcd
10、etcd上报事件【pod调度过后的信息（node: node-02）】，给api-server
11、其他节点的kubelet专门监听 【pod调度过后的信息（node: node-02）】 事件，集群所有节点kubelet从api-server就拿到了 【pod调度过后的信息（node: node-02）】 事件
12、每个节点的kubelet判断是否属于自己的事情；node-02的kubelet发现是他的事情
13、node-02的kubelet启动这个pod。汇报给master当前启动好的所有信息
生命里面很多事情，沉重婉转至不可说，我想你明白，正如我想我明白你。
