云原生技术核心——k8s 目前已经逐渐成为计算机、云计算、大数据等行业的技术标杆和基础。k8s目前也已经趋于成熟，很多大厂小厂都用到这一技术。 在此和大家一同学习，本人也是首次学习该项技术，冒昧把笔记分享在这个方便大家交流学习。分享中如有写的不合适的地方欢迎大家指正。

k8s 第一章

k8s全称kubernetes，这个名字大家应该都不陌生，k8s是为容器服务而生的一个可移植容器的编排管理工具，越来越多的公司正在拥抱k8s，并且当前k8s已经主导了云业务流程，推动了微服务架构等热门技术的普及和落地，正在如火如荼的发展。那么称霸容器领域的k8s究竟是有什么魔力呢？

首先，我们从容器技术谈起，在容器技术之前，大家开发用虚拟机比较多，比如vmware和openstack，我们可以使用虚拟机在我们的操作系统中模拟出多台子电脑（Linux），子电脑之间是相互隔离的，但是虚拟机对于开发和运维人员而言，存在启动慢，占用空间大，不易迁移的缺点。举一个我亲身经历过的场景吧，之前在vmware中开发了一个线下平台，为了保证每次能够顺利使用，我们就把这个虚拟机导出为OVF，然后随身携带，用的时候在服务器中部署，这里就充分体现了虚拟机的缺点。

接着，容器化技术应运而生，它不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境即可，而且启动速度很快，除了运行其中应用以外，基本不消耗额外的系统资源。Docker是应用最为广泛的容器技术，通过打包镜像，启动容器来创建一个服务。但是随着应用越来越复杂，容器的数量也越来越多，由此衍生了管理运维容器的重大问题，而且随着云计算的发展，云端最大的挑战，容器在漂移。在此业务驱动下，k8s问世，提出了一套全新的基于容器技术的分布式架构领先方案，在整个容器技术领域的发展是一个重大突破与创新。

那么，K8S实现了什么？

从架构设计层面，我们关注的可用性，伸缩性都可以结合k8s得到很好的解决，如果你想使用微服务架构，搭配k8s，真的是完美，再从部署运维层面，服务部署，服务监控，应用扩容和故障处理，k8s都提供了很好的解决方案。

具体来说，主要包括以下几点：

服务发现与调度
负载均衡
服务自愈
服务弹性扩容
横向扩容
存储卷挂载
总而言之，k8s可以使我们应用的部署和运维更加方便。

介绍

学习视角

介绍说明：
	k8s前世今生
	k8s框架
	k8s关键字含义
	
基础概念：
	什么是pod
	控制器类型
	k8s网络通讯模式
	
k8s:
	构建k8s集群
	
资源清单：
	资源
	掌握资源清单的语法
	编写pod
	掌握pod的生命周期(重点)
	
pod控制器：
	掌握各种控制器的特点以及使用定义方式
	
服务发现：
	掌握syc原理及其构建方式

存储：
	掌握多种存储类型的特点，并且能够在不同环境中选择适合的存储方案。
	
调度器：
	掌握调度器原理，能够根据要求把pod定义到想要的节点运行。
	
集群安全机制：
	集群的认证、签权、访问机制、原理及流程
	
HELM: 
	linux yum  掌握HELM原理  HELM模板定义   HELM
	
部署一些常用插件

运维：
	kuberadm源码修改
	k8s高可用架构

特点

1.轻量级
2.开源
3.弹性伸缩
4.负载均衡：
	IPVS
5.

k8s学习流程

Borg系统介绍

k8s架构图

k8s架构分为：Master服务器，node节点

Master服务器：
	scheduler:
		scheduler把任务交割api server。 api server将这个请求写入etcd。 也就是说scheduler不会和etcd进行直接交互。
	rc(replication colltroller):
		rc诗歌控制器，用来维护副本的数量。 当副本数不满足期望值时候，rc负责把副本数改写到期望值。也就是删除对应pod或者创建对应pod。
		

什么是etcd?

	etcd的官方将它定义为一个可信赖的分布式键值存储服务，它能够为整个分布式集群存储一些关键数据，协助分布式集群正常运转。
特点：
	1.天生支持集群化
	2.扩容方便
	3.键值存储
etcd存储有两个版本，一个是v2,一个是v3
	推荐k8s集群使用etcd v3。 k8s v1.11之后v2已经弃用。 如果是1.11版本之前就要考虑对etcd进行备份操作了。

etcd架构图

这里采用的是http协议，进行cls的构建服务。
（k8s也是用http协议进行的cls构建）
为什么用http协议？
	因为http协议天生支持很多操作---》put get change ....
	
Raft：
	读写的一些信息都会存在这里，为了防止数据损坏 还有个WAL预写日志。 也就是说，如果相对里面的数据进行修改，那么需要先写日志，先存一份日志， 并且会定期对这些日志进行完整备份。 并且合并完毕的大日志，会写到磁盘。

各个组件的作用

APISERVER：所有服务访问统一入口
CrontrollerManager：维持副本期望数目
Scheduler：负责介绍任务，选择合适的节点进行分配任务
ETCD：键值对数据库  储存K8S集群所有重要信息（持久化）
Kubelet：直接跟容器引擎交互实现容器的生命周期管理
Kube-proxy：负责写入规则至 IPTABLES、IPVS 实现服务映射访问的
COREDNS：可以为集群中的SVC创建一个域名IP的对应关系解析
DASHBOARD：给 K8S 集群提供一个 B/S 结构访问体系
INGRESS CONTROLLER：官方只能实现四层代理，INGRESS 可以实现七层代理
FEDERATION：提供一个可以跨集群中心多K8S统一管理功能
PROMETHEUS：提供K8S集群的监控能力
ELK：提供 K8S 集群日志统一分析介入平台

原理

1.pod的概念

 民间将pod定义为两种形式，首先自主式pod, 也就是非控制器管理的pod。 自主式pod，一旦死亡就没有人将起拉起来。 

1.同一个pod下，容器的端口不可以冲突， 因为同意个pod下所有容器是共用一个网络栈的。【个人理解是所有容器共用一个ip】, 如果端口冲突，是无法启动的，或者出于无限重启状态。

2.除此之外，同一个pod下不同的容器既共享网络，也共享存储卷。

1.1 RC、RS、Deployment

在k8s新版本中，建议使用RS来取代RC.
	首先RS和RC本质上是一样的。但是RS是集合的形式，方便对拥有公有属性的容器进行管理。 

RS不支持滚动创建，但是Deployment支持。
	deployment创建的时候，会创建一个RS,RS例如创建了三个pod， 那么例如这三个pod的版本是v1.、
	那么如果我们想将pod更新成v2. 时机上deployment会创建一个RS-1。 RS-1会逐个启动三个V2版本的容器，每次启动一个V2版本的容器，就会退出一个RS下面的一个V1版本的容器，直到单个V1 的容器全部被替换之后。 然后RS被停用。
	注意这里是RS被停用，不是被删除，因为这里是为了保证版本可以从V2 回溯到V1

1.2 HPA（HorizontalPodAutoScala）

特点：
	1.仅适用于Deployment 和 ReplicaSet。
	2.是根据cpu的利用率来扩容的。
		例如现在RS下面运行了两个pod,  这时候定义一个HPA（HPA是基于RS去定义的）例如HPA有如下定义内容：
			CPU 》=80
			Max = 10
			Min = 2
		也就是这个时候回去监控这些pod的cpu利用率，当cpu利用率>=80的时候， RS会去创建一个新的pod, 直到达到最大值(10), 当然当我们在创建到底n个pod之后，cpu的平均利用率已经达不到80，就不会继续创建了。 如果n个pod下，cpu利用率减少了，这时候又会动态的减少pod， 但是不会低于min个pod.
	所以：HPA实现了水平自动扩展的问题。