k8s原名：Kubernetes
前世今生
1、时间线
Mesos：分布式资源管理框架，2019年5月，Twitter公司抛弃Mesos，采用k8s
Docker Swarm：2019年7月，阿里云宣布将Docker Swarm剔除
k8s：轻量级（消耗资源小），开源，弹性伸缩，负载均衡（实现了模块之间的负载均衡，最新版本采用IPVS框架）
2、本课程的适用人群
软件工程师、测试工程师、运维工程师、软件架构师、项目经理
知识图谱
接下来要学习的内容：
介绍说明：KUbernetes 框架、KUbernetes关键字含义
基础概念：什么是 Pod、控制器类型、K8S 网络通讯模式
Kubernetes：构建 K8S 集群
资源清单：资源、掌握资源清单的语法、编写 Pod、掌握 Pod 的生命周期（重点）
Pod 控制器：掌握各种控制器的特点以及使用定义方式
服务发现：掌握 SVC 原理及其构建方式
存储：掌握多种存储类型的特点、并且能够在不同环境中选择合适的存储方案（有自己的见解）
调度器：掌握调度器原理、能够根据要求把Pod、定义到想要的节点运行
安全：集群的认证、鉴权、访问控制、原理及其流程
HELM：Linux yum、掌握 HELM 原理、HELM 模板自定义、HELM 部署一些常用插件
运维：修改Kubeadm、达到证书可用期限为 10年、能够构建高可用的 Kubernetes 集群
服务分类
- 有状态服务：DBMS
- 无状态服务：LVS APACHE
1、组件说明
下面的内容第一次听完全不懂，需要多理解，多反复。不光老师的笔记重要，老师说的话更重要。
k8s的前身是伯格（Borg）系统，采用Go语言的编译版（或重构版）。因此下面的学习思路是：先学习伯格（Borg）系统，再学习k8s调度系统。
上图可以看出：Borg系统由若干BorgMaster和Borglet组成，BorgMaster负责请求分发（整个集群的大脑），真正工作的节点是Borglet，比如：如果有对应容器要运行（比如有计算能力），是通过Borglet提供的。
为了防止BorgMaster单节点故障，因此出现了很多副本（后面叠放的），并且副本数目是有讲究的。可以是1、2、4、6个吗？对于高可用集群来说，一般需要满足：副本数目最好是3、5、7、9个（即大于1的奇数个）。不能为1个，因为1个节点会产生单点故障，单数个是为了保证投票时必须倾向某一方。
还可以发现图的最上方有几个访问方式：通过浏览器（web browsers）、命令行（command-line）、文件读取（borgcfg），在k8s中也会有这几种方式进行调度集群的管理。这三种方式会被接入到BorgMaster系统中，理解请求后再做分发。分发的概念很重要，即请求发送过来之后交给谁去处理，分发由scheduler（调度器）负责，所有任务到了scheduler之后会被分发到不同的节点去运行（注意：并不是scheduler和Borglet交互，而是scheduler把数据写入到Paxos中（Paxos是Google的键值对数据库），由Paxos存储。Borglet会实时地在Paxos数据库中进行监听，如果发现有对应请求了，则会把这一请求取出来（消费））。k8s与之类似。
该架构图为C/S架构，一部分是master服务器（上面的红框），一部分是node结点（下面的红框）。master是领导者，node是工人（执行者）。
领导者中包含：
scheduler（任务调度器）：任务过来之后需要通过scheduler把各自的任务分发至各自的node里。注意：在Borg系统中scheduler会写入到Paxos数据库里；k8s做了些更改：scheduler会把任务交给api server，api server负责把请求写入到etcd中，亦即scheduler并不会直接和etcd交互。replication controller（RC）：控制器。维护副本的数目（期望值）。一旦副本数不满足期望值，RC就负责把副本数改写到期望值（本质是创建或删除对应的Pod）。api server：一切服务访问的入口。scheduler需要和api server交互，RC需要和api server交互，kubectl（命令行管理工具）需要和api server交互，web UI需要和api server交互，etcd也需要和api server交互。可以发现api server是非常繁忙的，为了减轻其压力，每个主键还可以在本地生成一定的缓存，并不需要每件事情都到api server中去申请。接下来api server会去操作etcd。etcd：etcd在k8s中扮演的角色类似于Borg系统中的Paxos数据库。etcd是采用Go语言编写的键值对数据库，在k8s中起到持久化的作用。etcd的官方将其定义为一个可信赖的分布式（扩容方便）键值存储（k-v结构）服务，它能够为整个分布式集群存储一些关键数据，协助分布式集群的正常运转（保存分布式集群的需要持久化的配置文件、配置信息，一旦集群死亡，就可以借助etcd里的信息进行数据恢复）。etcd的存储有两个版本，一个是v2版，一个是v3版。v2版会把所有数据写入到内存中，v3版会引入本地持久化操作（关机以后并不会造成数据损坏，会从本地磁盘进行恢复）。
etcd的内部架构是采用HTTP协议的C/S架构（k8s也是采用C/S架构），因为HTTP协议天生支持很多操作方式（如put、get等）。Raft是读写信息，为了防止信息损坏，还有一个WAL（预写日志），如果想对数据进行更改，首先生成一个日志（先存一下），并且定时对日志进行完整备份。实时把日志写入到磁盘中进行持久化。
执行者中包含：
kubelet：需要安装kubelet，kubelet的作用是：和docker进行交互，操作docker去创建对应容器，维护Pod的生命周期。kube proxy：需要安装kube proxy。kube proxy的作用是：写入规则到iptables或ipvs中实现Pod与Pod之间的访问、负载均衡。默认操作对象是操作防火墙(firewall)实现Pod映射container：需要安装docker
其他组件：
CoreDNS：可以为集群中的SVC创建一个域名IP的对应关系解析，在集群中访问其他Pod时，不需要通过Pod的ip地址，而是通过CoreDNS生成的域名实现访问。也可以实现负载均衡。DASHBOARD：给 K8S 集群提供一个 B/S 结构访问体系INGRESS CONTROLLER：官方k8s集群只能实现四层代理，INGRESS可以实现七层代理，即可以根据主机名、域名进行负载均衡FEDERATION：提供一个可以跨集群中心多K8S统一管理功能PROMETHEUS：提供K8S集群的监控能力ELK：提供 K8S 集群日志统一分析接入平台
2、基础概念
2.1 什么是Pod？
自主式Pod
不是被控制器管理的
Pod。对于传统的
docker容器，在主机上运行的每一个容器都是独立存在的，通过名称空间进行隔离，每个容器都有自己的ip地址。但是在k8s移植时就不太容易了，比如想把一个没有在容器运行过的环境，把它迁移到k8s上，就比较难迁移。因为有些软件，比如lamp，a可能和php之间有联系，如果将他们分来，他们是不同的地址，还需要配他们的反向代理。
有些组件应该在一起，并且还能够直接互相见面，也就是通过
localhost可以直接访问到，但是如果采用标准的容器方案（图6），就不可以访问到，除非把两个不同的镜像封装在同一个容器内部，或者是第二个容器采用第一个容器的网络栈，但是安全性会有隐患。k8s给我们建立了
Pod。先启动第一个容器。只要运行了Pod该容器就会被启动。假设在Pod里定义了两个容器，两个容器共用pause的网络栈（亦即这两个容器没有独立的ip地址，有的只是Pod的地址）。控制管理器的Pod
被控制器管理的
Pod。
2.2 网络通讯方式
解决的问题：Pod与Pod间是如何通信的？Pod与外部是怎么通信的？
