目录
2. K8S 主从设备模型（Master-Slave 架构）
一.k8s发展进程（前身）
问题：若将容器集群化，要如何管理？
① 早期是mesos（Apache基金会）早期只作为资源管理平台，开源、分布式的管理框架，后来被推特看上，做为基础管理平台，大规模盛行
② 2019年推特宣布不用mesos、而全部使用kubernetes
③ mesos 官方公布，可以在我的平台上管理k8s（borge）
但是k8s与底层虚拟化相性很简单，未必需要多一步使用mesos
④ docker swarm ：docker 父公司的产品，他也是一种 docker 集群化管理的解决方案，
优势：轻量
但是相对于K8S而言，实现的功能还是比较少，例如k8s 的 滚动更新、回滚，可以实现，但是很复杂，除此之外大规模集群的使用和管理还是很强大的
⑤ kubernetes 稳定、适合生产、全面，成为了主要的解决方案——》谷歌
kubernetes的名字来自希腊语，意思是“舵手” 或 “领航员”,K8s是将8个字母“ubernete”替换为“8”的缩写。
即衍生出了资源管理器/资源管理框架（管理工具）
总结：
MESOS APACHE 分布式资源管理框架 2019-5 Twitter 》 Kubernetes
Docker Swarm 2019-07 阿里云宣布剔除 Docker Swarm
Kubernetes Google 10年容器化基础架构——》borg架构(内部资源管理器)
随着docker 流行，Borg 派出几个内部工程师，使用go语言以Borg系统设计思路
设计了一款新的资源管理系统——》kubernetes ,并且开源贡献给了容器基金会——》当前的标准
二.k8s的特点
① 轻量级
一些解释性语言：例如Python/JavaScript / Perl /Shell，效率较低，占用内存资源较多
使用go语言——》编译型语言，语言级别支持进程管理，不需要人为控制，所以以go开发的资源消耗占用资源小
[List-watch] + informer 二级缓存
② 开源
③ 自我修复（控制器控制pod，保证pod可以维持我们所期望的副本数量）
scale 副本集：
1.在节点故障时“重新启动”失败的容器，替换和重新部署，保证预期的副本数量；杀死健康检查失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断。
2.对异常状态的容器进行重建（先创建、再删除），目的是保证业务线不中断
3.节点上的pod 无限”重启“——》故障项
④ 弹性伸缩（自动）
手动弹性伸缩（针对于pod），当I/O读/写、磁盘、内存的压力（单个pod）> 80%，修改replicasets:3->4更新一下nginx.yml
自动：Yml --> 阈值 cpu使用率 > 80% ——》触发扩容pod （CPU使用上限，docker-cgroup k8s ---> 1、limit
2、configmap-配置文件 ）
使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性；业务低峰时回收资源，以最小成本运行服务。
弹性——》人为只要指定规则，满足条件时，就会自动触发 扩容或缩容的操作
伸缩——》扩容和缩容（节点 应用类型nginx）
⑤ 自动部署和回滚
打好容器的镜像
一条指令就可以自动部署
⑥ 服务发现(类比于docker中的-p )和负载均衡
kube-proxy 3种模式：
① userspaces
② iptables
③ ipvs（默认）
追加——————》 ipvs 和iptables 有什么区别，ipvs有什么优势？？？
K8S为多个pod（容器）提供一个统一访问入口（内部IP地址和一个DNS名称），并且负载均衡关联的所有容器，使得用户无需考虑容器IP问题
使用IPVS（章文嵩）框架--->“替代”iptables
⑦ 机密（加密配置）和（普通）配置管理（secret——》安全/认证加密性的数据 configmap---》例如配置文件）
管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高敏感数据安全性。并可以将一些常用的配置存储在K8S中，方便应用程序使用。
⑧ 存储编排(静态、动态)
静态：volume （docker run -itd -v /tmp:/tmp tomcat:latest /bin/bash ）--》挂载在本地
动态：统，无论是来自本地存储，公有云（如AWS），还是网络存储（如NFS、GlusterFS、Ceph）都作为集群资源的一部分使用，极大提高存储使用灵活性。
⑨ 批处理
提供一次性任务（job），定时任务（crontab）；满足批量数据处理和分析的场景
目的：
K8S 目标是为了让部署容器化应用、管理容器集群资源更加简单高效
三.基本组件
1、Pod（最小的资源单位）
一个pod会封装多个容器组成一个子节点的运行环境即最小部署单元，一组容器的集合分为（基础容器+初始化容器+业务容器）
2.基础容器：
维护整个Pod网络和存储空间在node节点中操作，启动一个实例时，k8s会自动启动一个init容器，然后启动基础容器最后启动主容器
3. 初始化容器(initcontainers)
Init容器必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法。如果 Pod 的Init容器失败，k8s 会不断地重启该Pod（为了让init容器可以启动完成），直到 Init容器成功为止。然而，如果 Pod对应的重启策略（restartPolicy）为Never，它不会重新启动。
4.业务容器
即运行业务的容器，往往是并行启动。
总结：
Pod是短暂的 （叙述的是其生命周期）其意思就是pod的生命周期是短暂的
① 副本集
② 自动修复
③ 弹性伸缩
④ 探针
⑤ 回滚
⑥ service的服务发现和kube-proxy的负载均衡
以上共同保障Pod的可用性和健康性——》保障业务正常运行
四．为什么需要Kubernetes，它能做什么？
容器是打包和运行应用程序的好方式。**在生产环境中，你需要管理运行应用程序的容器，并确保不会停机。 例如，如果一个容器发生故障，则需要启动另一个容器。如果系统处理此行为，会不会更容易？
这就是 Kubernetes 来解决这些问题的方法！ Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。
K8S是Google开源的容器集群管理系统，在Docker等容器技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。 其主要功能如下：
1.使用 Docker 等容器技术对应用程序包装（package）、实例化（instantiate）、运行（run）。
2.以集群的方式运行、管理跨机器的容器。
3.解决 Docker 跨机器容器之间的通讯问题。
4.K8S 的自我修复机制使得容器集群总是运行在用户期望的状态。
五．k8s架构
1.k8s自动扩容原理
如上图，当原来的三个pod中的业务容器中的cpu负载率超过了一个阈值后就会进行扩容，当然在扩容的前提下还是根据docker cgroups资源限制，如上图，基于资源限制，当达到所设置的cpu负载率的阈值后会自动根据cgroup中的设置例如限制cpu资源或者内存资源。
当然所扩容的业务容器也是有区分的：
有状态：加入后需要个性化设置
无状态：加入后不需要个性化设置，直接配置就可以使用
2. K8S 主从设备模型（Master-Slave 架构）
组件 作用
master节点
apiserver 所有服务的访问入口
controller-manager 负责根据预设模板创建pod，维持pod等资源的副本期望数目
scheduler 负责调度pod，通过预选策略、优选策略选择最合适的node节点分配pod
etcd 分布式键值对数据库，负责存储K8S集群的重要信息（持久化）
work node节点 –
Kubelet 跟apiserver通信汇报当前node节点上的资源使用情况和状态，接受apiserver的指令跟容器引擎交互实现容器的生命周期管理
Kube-proxy 在node节点上实现pod的网络代理，维护网络规则和四层负载均衡规则，负责写入规则到iptables或ipvs实现服务映射访问
容器运行时docker 运行容器，负责本机的容器创建和管理工作