k8s的前身borg

BorgMaster类似于是中心调度的大脑，Borglet是一些真正运行服务的节点，其中包含某些节点的副本，一般来说节点的数量都是奇数的为了防止投票的时候出现平手的现象一般都是用奇数个节点。

scheduler调度器

scheduler将数据写入Paxos数据库当中之后再发给Borglet去消费这些数据。

K8s的架构

master服务器分为三部分

• scheduler ： 调度器
• replication controller ：配置控制器，负责控制副本数量得，伸展和收缩容器的数量
• api server：所有数据访问和请求的接口

外部组件

kubectl： 命令行管理工具也会与api server进行交互
webUI：也是与api server进行交互
etcd：api server接收到操作的请求之后访问etcd，起到了持久化的作用

etcd介绍

etcd一个可信赖分布式键值存储服务，他本身就支持分布式存储，不需要其他的中间件的存在。用于为整个分布式集群存储一些关键数据，协助分布式集群的正常运转。
在k8s集群中使用EtcdV3，v2版本已经在v1.11弃用。V2版本是没有做备份操作的，需要单独做备份，v3是有做持久化的。

• httpserver提供所有的服务的接口
• raft存储着所有的信息
• wal生成日志，将每条数据的都备份到Entry记录当中，并且会定时的对数据进行快照完整备份。因为不可能随时进行完整备份，也不能一直用临时备份，可能会导致增量数据太多后面再进行完整备份的时候太麻烦，所以隔一段时间就进行一下快照。同事也会将数据存储到本地磁盘当中进行持久化设置。

底层的节点的作用

kubelet
可以选择使用的容器类型，常见的是docker，kubelet管理docker
kube proxy
pod与pod之间的访问和负载均衡需要依靠kube proxy来实现。默认是通过操作防火墙来实现pod的映射，新版本支持IPVS。

其他插件

coreDNS：可以为及群众的SVC创建一个域名IP的对应关系解析
dashboard：给k8s集群的bs访问体系
Ingress Controller可以进行七层代理
federation：提供一个可以跨集群中心多k8s统一管理的功能
prometheus：提供k8s集群的监控能力
ELK： 提供K8s集群日志的统一分析接入平台

Pod的概念

• 一个pod里面可以管理多个docker容器
• 每一个pod里面都具备一个pause容器，这个容器是创建pod的时候就会生成的一个容器，主要的作用就是为所有的进程隔离的容器提供一个统一的网络协议栈，这样两个容器看起来就像是运行在一个系统的网络环境下面的两个process。所以需要注意的是不能使用同样的ip和端口。如果pause和外界的html资源有联系的话，pause上面的资源也会被pod内所有其他的容器节点所共享。
• pod中的容器共用一个网络命名空间
• pod是临时性的，每次被销毁之后再创建就会改变为新的ip和端口

Pod存在的意义

1. 创建容器使用的是docker，一个docker对应一个容器一个进程，运行一个应用程序。如果运行多个程序就不方便管理内部的某一个线程，不能做统一管理
2. pod是多进程的设计方式，pod内部管理多个docker容器，并且还有管理容器的pause容器。
3. pod的设计支持亲密性应用
   • 应用之间可以进行交互
   • 内部都属于一个网络栈不需要单独设置其他的ip和端口
   • 两个应用需要频繁调用
4. 实现共享存储的机制，使用数据卷volume来做持久化存储，方式其中某个docker宕机，可以立即恢复数据

image拉取策略

apiVersion: V1
kind: Pod
metadata: 
	name: mypod
spec: 
	containers:
		- name: nginx
		  image: nginx:1.14
		  imagePullPolicy: Always
		  # IfNotPresent: 默认值，镜像在宿主机上不存在才拉取
		  # Always： Pod每次创建都会重新拉取一次
		  # Never: Pod永远不会主动去拉取这个镜像

pod调度的资源限制

apiVersion: V1
kind: Pod
metadata: 
	name: mypod
spec: 
	containers:
	- name: mysql
	  env:
	  - name: ADMIN_PWD
	  	value: "passwd"
	  #resources项用于配置调度资源的限制和要求
	  resources:
	  	request: #调度大小
	  		memory: "64Mi"
	  		cpu: "250m"
	  	limits: # 限制大小
	  		memory: "128Mi"
	  		cpu: "500m"

Pod的创建过程

master节点

1. create pod操作
2. 发送给apiserver
3. apiserver将新pod的信息记录在etcd中
4. sheduler 通过apiserver获得新节点
5. apiserver访问etcd将节点的信息传给sheduler
6. 使用调度算法把pod调度到某个node节点

node节点

1. kubelet访问apiserver
2. 通过读取etcd得到当前节点的pod
3. 使用docker命令创建容器

Pod的调度

影响调度的属性

1. pod资源限制对Pod调用差生的影响
2. 节点选择器影响pod调度，将node节点划分为不同的分组，在nodeSelector配置项下选择组名，就可以在固定的几个节点中进行调度。 对节点创建一个标签就可以使用标签来做分组

kubectl label node xx env_role=prod

3. 节点的亲和性影响pod调度： nodeAffinity
   • 硬亲和性： 约束条件必须满足，如果条件不满足就会处于等待状态
   • 软亲和性： 尝试满足，但是不保证一定可以

污点和污点容忍

Taint污点：节点不做普通分配调度，污点是节点的属性
针对特定的应用场景做分配

1. 专用节点
2. 配置特点硬件节点
3. 基于Taint驱逐

指令

查看污点情况

kubectl describe node k8smaster | grep  Taint

为节点添加污点

kubectl taint node [node] key=value:NoSchedule

污点值内容

1. NoSchedule：一定不会被调度
2. PerferNoSchedule ：尽量不被调度
3. NoExecute: 不会调度，并且还会驱逐Node已经有的Pod

污点容忍

即便是打上污点的节点也会被调度到，称为污点容忍

Pod控制器

ReplicationController && ReplicaSet && deployment
在集群上管理和运行容器的对象

Pod与Controller之间的关系

Pod通过controller来实现对于应用的运维（伸缩、滚动升级等）两者通过label标签来建立关系
工作负载会使用selector来对某一个label的app进行一定的管理

ReplicationController

用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来代替，而如果异常多出来的容器也会自动回收。

ReplicatSet

与ReplicationController本质上没有任何区别，只是名字布一样而已，而且replicaSet支持集合式的selector

Deployment

自动管理ReplicaSet，无需担心跟其他的机制不兼容的问题发生。（ReplicaSet不支持rolling-update但是deployment支持）

滚动更新：一个deloyment会设置一个Rs去管理pod，如果需要升级这些Pod的版本就会再生成一个RS从旧的Rs中拿一个pod重启之后再放入新的Rs中，如果中间的升级有问题的话还可以undo回滚，因为之前的旧的RS处于暂停的状态，并不会被删除，只有整个全部更新完毕才会删掉之前的RS。

应用场景

• 部署无状态应用
• 管理pod和ReplicaSet
• 部署，滚动升级等功能
• web服务、微服务中常用
  应用升级

#升级到1.15版本
kubectl set image deployment web nginx=nginx:1.15

查看升级状态

kubectl rollout status deployment web

查看升级版本

kubectl rollout history deployment web

回滚上一个版本

kubectl rollout undo deployment web

回滚到指定版本

kubectl rollout undo deployment web --to-revision=2

使用deployment部署一个应用

https://kubernetes.io/zh/docs/tasks/run-application/run-stateless-application-deployment/

HPV：平滑扩展根据利用率

v1中根据pod的cpu利用率来进行平滑扩展。HPV也是一个对象，当Cpu大于80的时候就需要被扩展，新建一个或多个pod，如果创建一个pod还没有低于八十，那就继续创建。最大数量pod是10，在利用率比较低的时候就会删除多余的pod。未来可以支持内存和用户自定义metrics扩容。

StatefulSet

docker比较支持的是无状态服务，但是如果希望让有状态的服务也能搭建到集群上面，就可以使用stateful来进行数据的持久化。
主要提供三个功能

1. 稳定的持久化存储：pod重新调度后还是能访问到相同的持久化数据，基于PVC实现的
2. 稳定的网络标识：Pod重新调度之后其podName和HostName不变，基于Headless Service来实现
3. 有序部署，有序扩展，Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行，只有当前一个的pod处于running或者是Ready状态下才可以启动新的pod。

DaemonSet

确保全部（或者一些）Node上运行一个Pod的副本，当有Node加入集群当中时，也会为他们新增一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。
如果被打上污点的pod就不会被参与调度。

使用demonSet的一些典型的用法：

• 运行集群存储demon，在每个Node上运行的glusterd、ceph
• 在每个Node上面运行日志收集deamon
• 在每个Node上运行监控daemon

cron Job

负责批处理服务，仅执行一次的任务，保证批处理任务的一个或多个pod成功结束

cron job管理基于时间的job，即

• 在给定时间点只运行一次
• 周期性地在给定时间点运行

服务发现

应用场景：客户端想要去访问一组pod的时候，这几个pod有一些共同点（同一标签 or 同一deploy管理）
service去主动收集这些pod的服务，service是通过标签去收集这些pod的。
service有IP和端口，client可以通过这些端口和IP去间接访问pod服务（轮询）