01_Kubernetes基础

Kubernetes为什么叫K8S：因为K和S之间有8个字母

为什么需要K8S

对于云计算来说有自己的交互标准

Paas的下一代标准就是容器化，容器的集群化有没有很好的方案？有需求就会有产品，这个产品就叫做资源管理器。
首先是Apache的MESOS，最开始不是为容器化诞生的，而是作为最基础的资源管理器，是开源的分布式资源管理框架。后被推特选中作为其基础平台大规模盛行，但是好景不长，2019年推特宣布不使用MESOS，全面使用K8S。
Docker SWARM是Docker的总部诞生的一款资源管理器，主要实现的是Docker的集群化方案。新版Docker已经和SWARM融为一体了，SWARM已经成为了Docker内部的组件功能。安装Docker之后Docker SWARM init就可以声明一个Docker集群，而老版本中需要附加一些组件（etcd)才可以实现。首先Docker SWARM很轻量，本机消耗的额外资源只有几十MB而已，对于一个集群化资源管理器来说相当于没有。那为什么我们选中的是K8S而不是SWARM?主要原因是它的功能相较于K8S还是太单一，太少。K8S功能全面，非常适合企业的运行。

K8S的发展

为什么突然就蹦出来一个K8S成为企业选择的主流方案了，Docker官方的SWARM为什么不好使？
原因是K8S的靠山是Google。Google在10年前就已经将容器化作为其基础架构了，有一个组件叫borg，它就是Google内部管理容器的一个框架的资源管理器。其它的公司也想用，但是Google不对外开放，不差钱。随着Docker的火爆，越来越多的公司介入容器的资源管理器，此时Google站出来说话了，完用未来的趋势不是我的borg框架就尴尬了，于是Google公司派了几名工程师采用GO语言对borg系统进行翻写，采用了borg的一些设计思路开发出了新的组件也就是K8S。自称K8S诞生，并且开源给了容器基金会。成为了当前的标准

K8S有什么样的特点

1.轻量级
对于现存的资源管理器大多采用解释型语言开发，像Java等，解释型语言效率低下，作为管理器来说日常工作非常繁忙，并且解释型语言会消耗大量的内存，所以运行起来之后并不轻量。K8S采用的是GO语言，GO语言被誉为现代的C语言，GO也是解释型语言，效率跟C看齐，但是比C语言好的是在语级别支持进程管理，不需要人为的去控制。因此由GO语言开发的K8S对系统占用是非常小的。因此轻量级不是说功能少，而是消耗的资源少。
2.开源
3.弹性伸缩
当资源不够用的时候可以扩展资源，并且扩展的过程是平缓的升级，不能说又是改配置，又是重启。在主节点通过一条命令就可以将一些节点剥离出集群调度，即就是当访问量不需要这么多节点的时候就可以释放这些节点的资源。
4.负载均衡
K8S内部已经实现了模块之间的负载均衡，完全不需要搭载调度器去实现，完全由K8S本机去实现，并且采用IPVS的框架

框架及组件说明

Google borg架构

BorgMaster：负责请求分发，相当于大脑
高可用集群副本数目最好是>=3的奇数。
为什么是奇数？投票的时候方便决策

K8S架构

组件说明：
APISERVER：所有服务访问统一入口
CrontrollerManager：维持副本期望数目
Scheduler：负责接受任务，选择合适的节点进行分配任务
ETCD：键值对数据库储存K8S集群所有重要信息（持久化）
Kubelet：直接跟容器引擎交互实现容器的生命周期管理
Kube-proxy：负责写入规则至IPTABLES、IPVS实现服务映射访问的

COREDNS：可以为集群中的SVc创建一个域名IP的对应关系解析
DASHBOARD：给K8S集群提供 B/S结构访问体系
INGRESS CONTROLLER：官方只能实现四层代理，
INGRESS：可以实现七层代理，可以根据主机名，域名进行负载均衡
FEDERAT工ON：提供一个可以跨集群中心多K8S统一管理功能
PROMETHEUS：提供K8S集群的监控能力
ELK：提供K8S集群日志统一分析接入平台

etcd 的官方将它定位成一个可信赖的分布式键值存储服务，它能够为整个分布式集群存储一些关键数据，协助分布式集群的正常运转

etcd内部架构图

依然是一个采用HTTP协议进行C/S的构件服务，除此之外K8S也是采用这种方案。因为HTTP协议天生支持PUT,GET等等操作，包括授权认证，Raft里面存放的是所有的读写信息，并且为了防止这些信息出现损坏还有一个WAL，这是一个预写日志，即就是如果要对信息进行修改需要先生成一个日志，并且会定时对这些日志进行完整备份；因为随时进行完整备份消耗量太大，还会实时将增量日志写入本地磁盘进行保存。